MVC5を使用したエンタープライズレベルのアプリケーションアーキテクチャのベストプラクティスは何ですか？

Question

MVC5に基づいたエンタープライズレベルのアーキテクチャのベストプラクティスは何だろうと思っていました。 1つのソリューションで複数のレイヤーまたは複数のプロジェクトを選択できますか？そして、あるいは複数のソリューション？良いサンプルプロジェクトはありますか？

Hadee · Accepted Answer

私の質問は昨年に何度も訪れており、私が知っているように確かな答えはないので、できるだけ包括的な答えを提供することにしました。この回答は、実際のプロジェクトの経験に基づいており、専門家との協議はほとんどありません。

まず第一に、ソフトウェア設計プロセスでは、堅実な善と悪のようなものは何もないことに注意することが重要です。アプローチがプロジェクトで機能し、うまく適合する限り、それはrightであり、うまくいかない場合はwrongです。ソフトウェア設計には厳格な原則はありません。 _Project needs and specifications_があります。しかし、一般的には、_Design Patterns and Principles_を使用すると受け入れられ、プロジェクトはrobust、reliableおよび_easy to maintain_をさらに増やし、コードを_loosely coupled and highly cohesive_にします。
_Software Design and Architecture_の全体像は、プロジェクトを簡単に管理する方法と、将来の変更を維持する方法についてです。どのアプローチがあなたに最良の答えを与えるか考えてください。それはあなたに最適です。 Professionalismについて考えすぎないでください！あなたのプロジェクトは時間とともに成長し、より成熟します。あなたのプロジェクトについて考えてみてください！
最初のステップとして、エンタープライズレベルのアプリケーションアーキテクチャでは、常に_Separation of Concerns_またはSoCに従うようにしてください。つまり、プロジェクトのさまざまなレイヤーにさまざまな層が必要です。 _Data Access Layer_、_Domain Entities_、_Business Layer_、および_Presentation Layer_に対して、ソリューションで異なるprojectを使用することを強くお勧めします。 MVC5プロジェクトでは、_Class Library Project_、_Data Access Layer_、_Domain Entities_には_Business Layer_を、_Presentation Layer_にはMVCプロジェクトを使用することをお勧めします。
_Data Access Layer_は、データベースおよびデータベースの相互作用に直面するプロジェクトです。このプロジェクトにすべての_Entity Framework_または同様のエンティティを含めることができます。データベースレイヤーごとにレイヤーを分離するということは、プロジェクトデータウェアハウスを変更する場合、変更する必要があるのは、このプロジェクトと_Business Layer_の若干の変更だけです。ソリューション内の他のすべてのプロジェクトはそのまま残ります。したがって、MS SqlからOracleまたは_Entity Framework_からNHibernateに簡単に移動できます。
_Domain Entities_は、すべてのソリューションレベルのインターフェイス、クラス、列挙型、および変数を定義するために使用するプロジェクトです。このプロジェクトは、クラスとメソッドのソリューション全体で整合性を保ちます。ソリューション全体のすべてのクラスは、このプロジェクトのインターフェイスから継承されます。したがって、クラスまたはグローバル変数を変更するには1か所を使用します。これは、将来のソリューションで_Easy to Maintain_を意味し、プロジェクトに新しく参加した開発者にとって理解しやすいものです。
_Business Layer_は、_Business Entities_および_Business Services_を含むすべてのビジネスロジックを配置する場所です。このレイヤーについての全体的な考えは、すべてのビジネスメソッドと対話を保持する1つの場所を持つことです。このセクションでは、計算、オブジェクトの変更、および保存、取得、変更などを含むデータに関するすべてのロジックを実行する必要があります。このレイヤーをプロジェクトに含めることで、たとえば、1つのネイティブMVCと1つの_Web API_レイヤーなど、異なるコンシューマーを同時に持つことができます。または、さまざまなビジネスサービス利用者の仕様に基づいて、さまざまな給餌を提供できます。 MVCレイヤーのコントローラーセクションにビジネスロジックを配置しないようにすることを強くお勧めします。コントローラ内にビジネスロジックがあるということは、プレゼンテーションレイヤをビジネスロジックレイヤとして使用していることを意味し、_Separation of Concerns_に違反しています。そうすれば、あるプレゼンテーションレイヤーから別のプレゼンテーションレイヤーに変更したり、ソリューションにさまざまなタイプの消費者を入れたりすることは簡単ではありません。 MVCのコントローラーセクションをできるだけスリムに保つことをお勧めします。コントローラには、_View Models_に直接関連するロジックとメソッドのみが必要です。 _View Models_の詳細については、セクション_7_を参照してください。覚えておくべきことの1つは、ソリューションオブジェクトまたは_Business Services_に基づいて異なる_Business Entities_クラスを用意することをお勧めします。
MVCソリューションの_Presentation Layer_はMVCプロジェクトになります。ただし、ソリューションには、さまざまな消費者またはテクノロジー向けに、他のタイプまたは複数のプレゼンテーションレイヤーを含めることができます。たとえば、1つのソリューションに1つのMVCレイヤーと1つの_Web API_を含めることができます。通常、プレゼンテーションレイヤーを使用して、すべてのプレゼンテーションロジックを保持します。プレゼンテーションロジックには、ビジネスロジックやデータロジックに関連するものを含めないでください。質問は_Presentation logic_とは何ですか？ _Presentation logic_は、ビューモデルに関連するロジックです。ビューモデルは、ビューまたはページ用にカスタマイズされたオブジェクトです。ほとんどの場合、ビジネスオブジェクトはビューでの使用に適していません。一方、プレゼンテーションビューには通常、たとえば元のオブジェクト名とは異なる表示名など、いくつかの検証ロジックまたはプレゼンテーションロジックが必要です。これらの場合、プレゼンテーションロジックまたはビジネスロジックを独立して簡単に変更できるように、プレゼンテーションロジックをビジネスロジックから分離しておくことをお勧めしますプレゼンテーションロジック。ソリューションのプレゼンテーションレイヤーとしてMVCプロジェクトを使用する場合、すべてのビューモデルはMVCプロジェクトのModelsセクションに配置し、すべてのプレゼンテーションロジックはプロジェクトのControllersセクションに配置する必要があります。
最後に言っておくと、すべての多層ソリューションでは、たとえば、ビジネスエンティティをビューモデルに変換するために、オブジェクトからオブジェクトへのマッピングのためのフレームワークが必要です。 AutoMapper、BLToolkit、EmitMapperなど、この目的のためのツールがいくつかあります。

最後の言葉：questionと私のanswerをコメントして採点してください。