2

エンタープライズイントラネット内のデータベースに接続するアプリケーション（Winforms-application）を開発する必要があります。

アプリケーションをスケーラブルで保守可能かつ柔軟に保ちたいので、どのアーキテクチャを使用すべきかを考えています。これに関連して、私はN層とMVCパターンに困惑しました。

私の知る限り、2つのパターンの主な違いは、MVCはより三角形の構造（コンポーネントは相互に通信可能）であるのに対し、3層アプリケーションは各コンポーネント（n）が要求を転送することしかできない直線的な構造であるということです。コンポーネント（n + 1）。

したがって、私の考えは3層アプローチを取ることです。「プレゼンテーション層、Tier-1」がフォームを保持する場合、「ビジネス層、Tier-2」はTier-1とTier-3の間の情報とロジックを処理し、「データ層、Tier-3」はデータベースであり、ストアドプロシージャで動作します。

私の質問は：

これはあなたにとって合理的な乾燥のように聞こえますか？異なるマシンで単一層を実行することを計画している場合、N層が意味をなすと読んだので、これは実行する予定はありません。私が間違ったアプローチを選んだと思うなら、より良いアイデアは何でしょうか？

前もって感謝します。

4

2 に答える 2

5

MVCとn層は、さまざまな側面をカバーするさまざまなレベルの2つのアーキテクチャパターンです。同時に使用できます。それはどちらか一方ではありません。

MVCは、プレゼンテーション層に適用できるソフトウェアアーキテクチャであり、1つのコンポーネントはWindowsフォームです。（Windowsフォームが完全にMVC互換であるかどうかは、別の議論です。）

N層アーキテクチャはシステムアーキテクチャです（MVCアーキテクチャよりも高いレベルです）。基本的には、2つの層（最初の層としてWindowsフォームクライアントと2番目の層としてストアドプロシージャを備えたデータベース）を使用するか、3つの層（最初の層としてWindowsフォームクライアント、ビジネスロジックを備えたアプリケーションサーバー）を使用するかを決定します。 2番目の層として、3番目の層が3番目の層としてデータベース）。またはさらに短い：クライアントはデータベースに直接接続しますか、それとも間にアプリケーションサーバーがありますか？

ストアドプロシージャの使用が与えられているようです。この場合、データのクエリとストレージだけでなく、ビジネスロジックも提供する可能性があります。そのような場合、私は2つの層で行く傾向があります。

関連する可能性のあるその他の要因は次のとおりです。

  • 認証：データベース内のすべてのユーザーを設定することは可能ですか？または、アプリケーションサーバーでそれを実行し、単一のユーザーを使用してデータベースにアクセスする方が簡単でしょうか。ある種のシングルサインオンが必要ですか？

  • 承認：データベース内のすべての権限と権限を確認することは可能ですか？そうでない場合、安全なアプリケーションを作成するには3つの層が必要ですか？

  • データベースに直接アクセスすることを禁止するネットワークアーキテクチャに関する制限はありますか？

  • 数千人の同時ユーザーを想定しており、複数のサーバーをセットアップしてスケールアップしたいですか？

一般に、実装が簡単でコストが低いため（初期およびメンテナンス中）、階層を少なくする傾向があります。追加のティアのコストは、追加のティアに依存する要件によって正当化される必要があります。

于 2012-07-05T13:23:40.267 に答える
4


MVCおよびMVP、MVVMなどの他のMVC関連パターンは、アプリケーションのUIレイヤーに関連付けられているパターンです。（Winforms / Web / WPFまたはUIフレームワークが何であれ）。

基本的に、これらのUIパターンは、UIプレゼンテーション関連の側面からのUIロジックの緩い結合を促進します。それらは次のような利点を提供します：

  • 自動化された単体テストツールを使用して、UIロジックレイヤーユニットをテスト可能にします。（実際のUIを起動する必要はありません）
  • UIとUIロジックコンポーネント間の結合が緩いため、UIロジッククラスはより再利用可能になります。（ieControllersとModelsは複数のビューで使用できます）
  • Also give additional benefits which wouldn't be used commonly such as being able to save the status of a UI by serializing the Models etc..

MVC and N-Tiered architecture are not two opposite approaches from which you need to choose one or the other.
Depending on your requirenments, you can mix and match them to suite your application requirements.

For e.g. you can choose to have an overall 3-Tiered solution with UI, Business Logic and Data Access Layers. Within this you can choose to have your UI layer implemented in MVC style.

to clarifiy more, you can have your Business Logic layer as a set of services exposing business functionalities while communicating with the Data Access Layer for persistance. At the same time Controllers on your UI layer could access these Business layer services for business functionalites and build Models/ViewModels to suite the Views.
Implementations could vastly differer, this is just an example.

Basically these two patters can complement each other in offering a better solution.

于 2012-07-05T14:57:13.230 に答える