ASP.Netの3層アーキテクチャとMVC（モデル、ビューコントローラー）の違い
3層アーキテクチャがASP.NetのMVC（モデル、ビューコントローラー）とどのように異なるかを知りたいのですが、同じアーキテクチャが適用されるようです。
3層にはUser Services Layer、BusinessLayerとDataAccessLayerに対して、Model、View、Controllerがあります。これは同じアーキテクチャのようです。
2つのアーキテクチャの実際の違い、各レイヤーの違いについて誰かが説明できますか？
これは、AppleコアとAppleコアの違いを尋ねるようなものです。これらの2つのアーキテクチャは、相互に置き換わるものではありません。より正確だと思います。ビューは、3層アーキテクチャaugmentsMVCです。
MVCアーキテクチャ
Models：これらは、アプリケーションの「もの」を表します。後で説明するように、この層は近年少しあいまいになっています。
Views：ユーザーインターフェイス。ユーザーが操作するもの。
Controllers：ユーザーとモデルレイヤーの変更に応答するプログラミングコード
3層アーキテクチャ
3層アーキテクチャーでは、さまざまな責任を持つレイヤーがあります。
ユーザーサービス：（または「サービス」全般）このレイヤーは、「モデル」レイヤーの取得と変更を調整することについて詳しく説明しています。複雑なマルチステップアクションがここで実行されます
ビジネス層：これは、プログラミングコードにエッチングされたビジネスルールを表します。 「ビジネス」が望むことは、この層で実施されます。
Data Access Layer：永続データストアへのアクセスを担当する1つ以上のクラス。
MVCと交差する3層アーキテクチャの唯一の部分は、「ビジネス層」です。 MVCの「モデル」と3層アーキテクチャーの「ビジネス層」は、同じ目標を達成しようとしています。
MVCの「M」がぼやける
MVCの「モデル」層は近年拡大しています。私が見たことから、2種類、おそらく3種類のモデルがあります。
ドメインモデル：これらは、「ビジネス」が気にする「もの」を表します-ビジネスドメイン。これらのクラスは、ビジネスルールを適用するためにデータとそのデータを操作するすべてのプロシージャを保持します。多くの場合、ドメインモデルはデータベース内のテーブルに関連付けられています。これは、3層アーキテクチャの「ビジネス層」に適合するようです。
ビューモデル：これらは、ドメインモデルからのデータをビューに適したものにマッサージするために使用されるクラスです。ビューモデルはビジネスロジックを実装しておらず、サービスやデータへのアクセスも提供していないため、これは3層アーキテクチャのどこにも適合しません。
ビジネスモデル：複雑なアプリケーションでは、ドメインモデルをビジネスロジックから切り離す必要が生じます。ビジネスモデルには、データとビジネスルールを実装するためにそのデータを操作する手順が含まれ、ドメインモデルは「プロパティバッグ」（データを保持するだけで動作を含まないオブジェクト）に委任されます。ドメインモデルは、データベースとアプリケーション間の別の形式のデータ転送オブジェクトになります。
MVCのどこにもデータアクセスは記載されていません。場合によっては、データアクセスがMVCの「モデル」レイヤーに属していることがわかります。これは、これまで見てきたように、もはや明確なレイヤーではありません。アプリケーション全体を作成するために、MVCとペアである3層アーキテクチャを実際に見ます。一方は他方を増強または改善します。
- モデル
- ドメインモデル（MVC/3層）
- モデルを表示（MVC）
- （オプション）ビジネスモデル（MVC/3層）
- ビュー（MVC）
- コントローラー（MVC）
- データアクセス（3層）
- サービス（3層）
いくつかの交差点がありますが、それらは大きく分離しており、より大きなシステムのさまざまなコンポーネントを分離および分離するために一緒に使用されます。
いいえ、同じではありません。
MVCは、ユーザーインターフェイスコードを構造化するためのデザインパターンです。 3層アーキテクチャで使用でき、その場合、パターンはユーザーサービスレイヤーに属します。ただし、3層ではないアプリケーションのUIにも使用できます。根本的な永続性がないため、データアクセス層がない計算機。
MVCフロントエンドの3層アーキテクチャーでは、モデルとして使用されるドメインオブジェクトはビジネスレイヤーのオブジェクトですが、MVCパターンは実際にはどのような種類のオブジェクトであるかをモデルではなく、パターンでの役割のみを指定しますです。たとえば、MVVMバリアントでは、モデルはドメインオブジェクトの上にあるUI固有のアダプターです。この場合、モデルもユーザーサービスレイヤーに属します。
さまざまな答えがたくさんあることは知っていますが、これについて私の考えを説明します。
それはソフトウェアエンジニアリングで最も有名な答えです。
基本的にそれを見ると、さまざまな実装と理論上の違いに加えて、これらは類似のフローを備えた非常に類似したパターンです。
依存しているのは、構築しているアプリケーションです。単純なWebアプリケーションには、ORMを介してDBと通信するMVCレイヤーのみがある場合があります。より複雑なものは、ユーザー層のフロントエンドをMVCで処理し、複数のソースで構成されるデータ層で、BL層でより複雑な非ユーザー公開操作が発生する場合があります。