MVCと3層アーキテクチャの基本的な違いは何ですか?
-tierはアーキテクチャスタイルおよび[〜#〜] mvc [〜#〜]はデザインパターン =。
その点で異なります。
しかし、3層アーキテクチャスタイルでmvcパターンを使用できます。
そう:
プレゼンテーション層:MVCパターンの「コントローラーとビュー」。
ビジネス層:MVCパターンからの「モデル(データ)」。
データアクセス層:元のデータアクセス層。
大規模なアプリケーションでは、MVCはN層アーキテクチャのみのプレゼンテーション層です。モデルビューとコントローラーはプレゼンテーションにのみ関係し、中間層を使用してモデルにデータ層からのデータを取り込みます。
MVCは、ビューがプレゼンテーション、コントローラーがビジネスロジック、モデルがデータレイヤー(通常はEntity FrameworkなどのDALによって生成される)である3層アーキテクチャ全体としても使用できます。
理想的には、コントローラーを細くてバカにし、ロジックを「ビジネスコンポーネント」に渡します。これは本質的に中間層になります。
3層アーキテクチャでは、層間の通信は双方向です。 MVCでは、通信は単方向です。各「レイヤー」は左側のレイヤーによって更新され、次に右側のレイヤーが更新されます。「左側」と「右側」は単なる例示です。
通常、3層アーキテクチャは、3つの別個のネットワークノードに3つの別個のプロセスとして展開します。ただし、MVCは、単一のネットワークノードに単一のプロセスとしてデプロイするように設計されています。 (デスクトップアプリケーションなど)
3層のビジネス層には通常、ビジネスデリゲート、ビジネスファサード、ビジネスオブジェクト、サービスロケーター、データ転送オブジェクトなどの有名なパターンを実装するさまざまな層が含まれます。しかし、MVCはプレゼンテーション層で使用されるデザインパターンそのものです。
3層の目標は、ビジネスロジックをクライアントとデータベースから分離することです。そのため、複数のクライアントプロトコル、高いスケーラビリティ、異種データアクセスなどを提供します。 。
私はマイケルが彼の応答で言ったこととは異なるアプローチを取ります。
コントローラがビジネスロジックになることは決してありません。私にとって、ビジネスロジックはモデルレイヤーに属します。ただし、ビュー(およびある程度コントローラー)およびプレゼンテーション層の一部であるモデルは、MVCアプリケーションでは決してその一部ではありません。モデルはMVCアプリケーションの核心である必要があり、それがMVCアプリケーションで簡単に実装できるドメイン駆動設計です。
同じプロジェクト内にモデルを置く必要はないことを覚えておいてください(ASP.NET MVCと言えば)。まったく別のプロジェクトに常駐することができ、それでもアプリケーションのモデルとして機能できます。
プレゼンテーション層として機能するMVCアプリケーションは、多くの層を持つ巨大なプロジェクトでのみ機能しますが、質問者が求めた3層アーキテクチャでプレゼンテーション専用層として機能することはできません。
したがって、MVCは3層アーキテクチャの3つのレイヤのうち2つ(3つ目は、MVCアーキテクチャ自体の一部ではないデータレイヤになる可能性があります)になります。
ありがとう。
2つの間に関係はありません。 MVCはプレゼンテーション層のパターンです。 Model-View-Controller全体がプレゼンテーション層に存在します。
Modelは、Viewで表されるか、Viewから入力されるデータ(通常はVO)を保持するオブジェクトです。
Controllerは、リクエストを取得し(モデルにデータを追加する場合があります)、サービス層を呼び出します。次に、別の(または同じ)モデルを取得し、Viewに送り返します。
Viewはモデルを表示し、ユーザー入力をキャプチャするコンポーネントを提供します。 (通常、Webアプリケーションのテンプレートエンジン、またはデスクトップアプリケーションのUIコンポーネントです)。
3層(またはn層)アプリケーションについて話すときは、プレゼンテーション層(MVC全体)、サービス層(ビジネスクラス)、およびデータアクセス層で構成されるアプリケーション全体のアーキテクチャについて話します。
サービス層(およびその背後のすべて)は、MVCのコントローラーの背後に隠されています。
3層アーキテクチャとは何ですか?
3層(レイヤー)は クライアントサーバーアーキテクチャ であり、ユーザーインターフェイス、ビジネスプロセス(ビジネスルール)、データストレージ、データアクセスが独立したモジュールとして、またはほとんどの場合別々のプラットフォームで開発および保守されます。 。基本的に、ティア1(プレゼンテーションティア、GUIティア)、ティア2(ビジネスオブジェクト、ビジネスロジックティア)、ティア3(データアクセスティア)の3つのレイヤーがあります。これらの層は、個別に開発およびテストできます。
DAL-データアクセスレイヤー(接続文字列とデータの読み取りおよび実行プロセスがあります)
BOL-ビジネスオブジェクトレイヤー(クエリがあります)
UI-ユーザーインターフェイス(フォームとコードビハインド)
詳細: 層アーキテクチャ
3層アーキテクチャは線形であり、クライアント層が実際にデータ層と通信することはありません。すべての通信は中間層を通過します。一方、MVCはビューがコントローラーに更新を送信し、モデルから更新を受信し、コントローラーがモデルを更新する三角形です。
( http://en.wikipedia.org/wiki/3-tier_architecture の「MVCアーキテクチャとの比較」を参照してください)
すべてのアプリケーションには、1つ以上の次のレイヤーがあります1)プレゼンテーションレイヤーまたはUIレイヤー2)ビジネスレイヤーまたはビジネスロジックレイヤー3)データアクセスレイヤーまたはデータレイヤー
層アーキテクチャ通常、各層はネットワークで分離されています。 I.E.プレゼンテーション層は一部のWebサーバー上にあり、ビジネスロジックのためにネットワーク経由でバックエンドアプリサーバーと通信し、次にネットワーク経由でデータベースサーバーと通信します。また、アプリサーバーがリモートサービスを呼び出すこともあります。 (支払い処理のためにAuthorize.netを言う)。
上記のタイプのより多くの層とより多くの機械が必要な場合があり、それはN層と呼ばれます
[〜#〜] mvc [〜#〜]は、コードの異なる部分が一部のアプリケーションでモデル、ビュー、コントローラーを表すプログラミング設計パターンです。たとえば、モデル層には、データを保存および取得するためのデータベースを呼び出す内部実装が含まれている可能性があるため、これら2つのことは関連しています。コントローラーはWebサーバーに常駐し、リモートでappserverを呼び出してデータを取得できます。 MVCは、アプリのアーキテクチャの実装方法の詳細を抽象化します。 モデル構築したいモデル表示はアプリケーションのUIを意味します制御はアプリケーションを制御するロジックを意味します
-tierは、単に実装の物理構造を指します。 MVC設計は多くの場合3層アーキテクチャを使用して実装されるため、これら2つは混同されることがあります。
IMOには、3層アーキテクチャとMVCの間に直接比較はありません。両方とも組み合わせで使用されるため、同じレンズを通して見る傾向があります。概念的には、一緒に使用する必要はありません。 しないMVCが提供するものを使用しない3-Tierアーキテクチャを持つことができます。
定義の部分については詳しく説明しませんが、簡単に言えば:
3-Tierはソフトウェアアーキテクチャアプローチであり、ユーザーインターフェース、ビジネスプロセスはロジック、データ層は独立して開発され、多くの場合別々のプラットフォームで開発されます。
[〜#〜] mvc [〜#〜]は一定期間にわたってソフトウェアパターンからアーキテクチャパターンに進化し、現在、すべての主要なフレームワークで見られます。
私の経験では、MVCは誤って記述された3層の単なる「流行」の用語であり、通信の一部がビジネスレイヤーを飛び回り、クライアントやデータレイヤーにもビジネスルールが混在しています。
私はそのように書かれたコードが嫌いです-MVCという用語は、HRリクルーターを混乱させて、古いプログラマー(「3層」として知っている)が仕事にマッチしないと考えるように設計されたに違いありません。
MVCの場合:MVCアーキテクチャは三角形です:ビューはコントローラーに更新を送信し、コントローラーはモデルを更新し、ビューはモデルから直接更新されます
3層:3層アーキテクチャでは、クライアント層がデータ層と直接通信することはありません3層モデルでは、すべての通信が中間層を通過する必要があります
Vikas Joshiソフトウェアエンジニア