.NET MVCプロジェクトアーキテクチャ/レイヤー

中規模のMVC Webアプリケーションのアーキテクチャを計画するとき、レイヤーを可能な限り分離してテストしやすいように実装するにはどうすればよいですか？（基本的にベストプラクティスに従います）データアクセスとして最初にコードを使用しているとしましょう。

「ビジネスロジック」の定義、およびデータレイヤーとのやり取りをどのように定義するかについて、私は苦労しています。車両販売アプリケーションを例にとると、ビジネスロジックは、特定の車両の税帯の計算、ガロンあたりのマイル統計の比較などのタスクを実行するクラスでしょうか。ビジネスエンティティ（例：車、バン、オートバイ）については、これらをDataContextクラスと共にデータレイヤーに配置します。

また、ビジネスとは対照的に、アプリケーションロジックを構成するものは何ですか。セッション/ユーザー入力の検証などを推測していますか？

したがって、たとえば、車のコントローラは、タイプと最良のmpgでフィルタされた上位10台の車をリストするアクション/ビューの結果を返す場合があります。たとえば、ICarRepository「リポジトリ」/ DIを使用して「carRepo」をコントローラに注入したとします。アクションメソッドのパラメータから車をフィルタリングします。var cars = carRepo.getCarsByType("hatchback");

したがって、リポジトリを使用してデータアクセスの知識をコントローラーから除外し、ドメインモデルを使用してビジネスロジックをコントローラーから除外しました-var result = new MpgCalculator（cars）; -DBからエンティティをロード/フィルタリングするだけではなく、最高の燃料効率を計算するために追加のロジックを実行する必要があるため、電卓クラスが必要だとしましょう。これで、ビューをレンダリングするためのデータセットがあり、リポジトリを使用してデータアクセスレイヤーから取得し、ドメイン固有のオブジェクトを処理して、そのデータに対してビジネス関連のタスクを実行します。

ここで間違いをしていますか？それでもリポジトリパターンを使用する必要がありますか、それともORMを分離してテストするためにインターフェイスに対してコーディングするだけですか？このトピックでは、具体的なデータアクセスクラスdbcontextがデータレイヤーにあるので、インターフェイス定義をドメイン/ビジネスレイヤーに入れる必要があります。つまり、データアクセステクノロジーが変更されても、他のレイヤーは影響を受けません。

これまでに調べたことから、私の構造は次のようになります。

MVCインターネットアプリケーション ->標準インターネットプロジェクト-ここのモデルはViewModelsです

ドメイン/ビジネスレイヤー ->コントローラーが関連するビューに渡す前にデータレイヤーからドメインエンティティを処理するために使用できるビジネス固有のクラス/モデル

リポジトリの抽象化が必要ですか？->特にORMを使用する場合、これについて多くの議論が聞こえます

データレイヤー ->エンティティクラス（Car、Van、Motorcycle）、DbContext-具象データアクセステクノロジーレイヤー

質問には多くの可動部分があり、多くの概念に触れていますが、中規模から大規模のMVCアプリケーションについて考えるときの基本的なアドバイスを次に示します。

プレゼンテーション<--->ビジネスロジック<--->データアクセス

まず、アプリを「MVCアプリケーション」と見なさないのが最善です。プレゼンテーションコンポーネントとしてMVCパターンを使用するアプリケーションです。このように考えると、ビジネスロジックの問題とプレゼンテーションの問題を区別するのに役立ちます。おそらく、小規模なアプリケーションがデータベースアクセスまですべてをMVC構造に積み重ねることは問題ありませんが、中規模から大規模なアプリケーションではすぐに受け入れられなくなります。

MVC（プレゼンテーション）

アプリでは、ASP.NET MVCコンポーネントは、表示（モデル）のためのビジネスデータの変換、ユーザーインターフェイス（ビュー）の表示、およびルーティング、認証、承認、要求の検証、応答の処理などの通信の問題を処理する必要があります。 （コントローラ）のように。他のことを行うコードがある場合、そのコードはMVCコンポーネントに属していません。

リポジトリ/ ORM（データアクセス）

また、アプリでは、データアクセスレイヤーは永続データの取得と保存に関係する必要があります。通常、これはリレーショナルデータベースの形式ですが、データを永続化する方法は他にもたくさんあります。永続データを読み取ったり保存したりしていないコードがある場合、そのコードはデータレイヤーに属していません。私は以前にSOMでORM /リポジトリの議論について自分の考えを共有しましたが、要約すると、いくつかの理由で、ORMをリポジトリと同じものとは見なしていません。

ビジネスの論理

これで、プレゼンテーションレイヤー（MVC）とデータレイヤー（リポジトリまたはORM）ができました。それ以外はすべてビジネスロジックレイヤー（BLL）です。取得するデータを決定したり、複雑な計算を実行したり、ビジネス上の決定を行ったりするすべてのコードがここにあるはずです。私は通常、ビジネスロジックを「サービス」の形式で編成します。これは、プレゼンテーションレイヤーが要求された作業を実行するために呼び出すことができます。私のドメインモデルはすべてここにあります。

あなたのアプローチ

ここで、あなたのアプローチが少し崩れます。リポジトリからデータを取得する場所としてMVCコントローラーを記述し、MPGCalculatorを呼び出していくつかの作業などを行います。コントローラーにこれを行わせずに、すべてをサービスに委任します。 BLLで。

言い換えれば、リポジトリとMPGCalculatorをコントローラに挿入しないので、コントローラに大きな責任が与えられます（すでに説明したすべてのコントローラのものを処理しています）。代わりに、BLLでサービスを処理してすべてを処理し、結果をコントローラーに返します。コントローラーは結果を正しいモデルに変換し、それを正しいビューに渡すことができます。コントローラーにはビジネスロジックが含まれておらず、コントローラーに注入されるのは適切なBLLサービスだけです。

この方法で行うと、ビジネスロジック（たとえば、一連の車両が与えられた場合、MPGを計算し、最も悪いものから順に並べ替えます）は、プレゼンテーションや永続性の問題から独立しています。それは通常、データ永続化戦略もプレゼンテーション戦略も知らないか気にしないライブラリにあります。

すべてがあなたの構造に合っているようです。MVCのモデルは "ViewModels"であり、コントローラーがドメインレイヤーと通信することについて、あなたが言及しているのはよくわかりません。コントローラーを使用してドメインレイヤーにアクセスし、「ViewModels」を使用して複数のドメインエンティティからの情報のビュー固有のコンパイルを特定のビューに適用する場合、これは意味があると思います。それがあなたがやっていることなら、おそらく大丈夫です。

MVCアプリケーションにドメインレイヤーを完全に抽象化する必要がある場合は、それを完全に抽象化する必要があるという考え方があります。個人的には、エンタープライズアプリケーションでそれを行うことを考えると、私はひどい精神的苦痛を引き起こします。

データレイヤーへのアクセスを管理するためにリポジトリパターンを使用することをお勧めします。これにより、テスト容易性と柔軟性が向上します。最も劇的な変更を加える傾向があるのは、UIとデータベースの2つです。データベースから直接取得している情報の一部が変更されて、データベース呼び出しではなくサービス呼び出しから取得する必要がある場合や、一部の情報が別の.edmxを必要とする別のデータベースに移動した場合を想像してください。ファイル。リポジトリパターンは、これをサポートする抽象化を提供します。