ASP.Netの3層アーキテクチャとMVC（モデル、ビューコントローラー）の違い

3層アーキテクチャがASP.NetのMVC（モデル、ビューコントローラー）とどのように異なるかを知りたいのですが、同じアーキテクチャが適用されるようです。

3階層では、我々は持っているUser Services Layer、BusinessLayerとDataAccessLayer、私たちは持っている一方でModel、View、とController。これは同じアーキテクチャのようです。

2つのアーキテクチャの実際の違い、各レイヤーの違いについて説明できますか？

これは、リンゴとリンゴの芯の違いを尋ねるようなものです。これらの2つのアーキテクチャは、相互に置き換わるものではありません。より正確な見方は、3層アーキテクチャがMVCを補強することだと思います。

MVCアーキテクチャ

• モデル：これらはアプリケーションの「もの」を表します。後で説明するように、この層は近年少しあいまいになっています。

• ビュー：ユーザーインターフェイス。ユーザーが操作するもの。

• コントローラー：ユーザーとモデルレイヤーの変更に応答するプログラミングコード

3層アーキテクチャ

3層アーキテクチャーでは、さまざまな責任を持つレイヤーがあります。

• ユーザーサービス：（または一般に「サービス」）このレイヤーは、「モデル」レイヤーの取得と変更を調整するためのものです。複雑なマルチステップアクションがここで実行されます

• ビジネス層：これは、プログラミングコードにエッチングされたビジネスルールを表します。「ビジネス」が望むことは、この層で実施されます。

• データアクセス層：永続データストアへのアクセスを担当する1つ以上のクラス。

MVCと交差する3層アーキテクチャの唯一の部分は、「ビジネス層」です。MVCの「モデル」と3層アーキテクチャーの「ビジネス層」は、同じ目標を達成しようとしています。

MVCの「M」がぼやける

MVCの「モデル」レイヤーは近年拡大しています。私が見てきたことから、2種類、場合によっては3種類のモデルがあります。

1. ドメインモデル：これらは、「ビジネス」が気にする「もの」、つまりビジネスドメインを表します。これらのクラスは、ビジネスルールを適用するためにデータとそのデータを操作するすべてのプロシージャを保持します。多くの場合、ドメインモデルはデータベースのテーブルに関連付けられています。これは、3層アーキテクチャの「ビジネス層」に適合するようです。

2. ビューモデル：これらは、ドメインモデルからのデータをビューに適したものにマッサージするために使用されるクラスです。ビューモデルにはビジネスロジックが実装されておらず、サービスやデータアクセスの種類も提供されていないため、これは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層でより複雑な非ユーザー公開操作が発生する場合があります。