c# - レイヤ ASP.NET MVC プロジェクト

Question

適切に設計されたプロジェクトの概念を理解しようとしています。

ASP.NET MVC を使用しており、階層化された (プラグ可能な) プロジェクトを作成しようとしています。

私が今持っている現在のプロジェクト構造はこれです：

1. LayeredProject- コントローラーを含む MVC プロジェクト

2. LayeredProject.EntityFramework- データベースに使用されるすべての POCO クラスが含まれています。（私はCode Firstアプローチを使用しています）

3. LayeredProject.Model- これには、プロジェクトで使用されるすべてのビジネス オブジェクトが含まれている必要があります。

プロジェクトが e コマース Web サイトであると言うと、次のように構成します。

• プロジェクトにはLayeredProject.EntityFramework、データベース テーブルに対応するクラスがあります。カテゴリ、製品、ユーザー。このプロジェクトは、データベースからのデータの保存と読み込みにのみ使用され、これらのオブジェクトは他の目的には使用しないでください。このプロジェクトにはプロジェクトへの参照がありLayeredProject.Modelます。

• プロジェクトでは、使用するすべてのオブジェクトを保存します。LayeredProject.Modelそれらのほとんどは、LayeredProject.EntityFrameworkPOCO のオブジェクトと使用される他のサービス クラスの正確なコピーです。

• LayeredProjectすべての ViewModels クラス、コントローラー、およびさまざまな UI ロジックを保持します。このプロジェクトにはプロジェクトへの参照がありLayeredProject.Modelます。

まず第一に、これがこれを行う正しい方法であるかどうかはわかりません。

EntityFrameworkそして、これが正しい方法である場合、プロジェクトとプロジェクトでPOCOクラスの複製が作成されるため、少し混乱しModelます。

これを理解するのを手伝ってください

Answer 1

階層構造を使用してプロジェクトを設計することも、MVCを使用して設計することもできます。コントローラとビューの部分はそのままにしておく必要があります。ビジネスロジック部分は、必要な数のレイヤーに分割できます。モデルは、期待するレイヤーの数の結果として得られるはずです。このために、ビジネスロジックを別のプロジェクトに保持します（必須ではありません。Webプロジェクト自体に存在する可能性があります）。そのプロジェクトのdllをMVCWebソリューションに参照します。データベースクエリの結果として生成されたモデルをWebソリューションに渡し、コントローラーの助けを借りてビューをレンダリングします（このスタイルを使用してプロジェクトを実行しました）

Answer 2

MVC プロジェクトには以下が含まれている必要があります。

• ビュー モデル: ビューのモデル、つまり、各ビューをレンダリングするための非常に特殊なモデル (これらのモデルは MVC の M ではありません)。このモデルには通常、ビューで表示または編集する必要があるデータと、ビューをレンダリングするために必要な追加の情報が含まれています。リストに入力します。AutoMapper や ValueInjecter などのマッパーを使用して、データをビジネス エンティティ (ビジネス レイヤーからのエンティティ) からビュー モデルに、またはその逆に移動できます。または、必要に応じて、ビジネス エンティティをモデル ビューのプロパティとして直接使用できます (ビュー モデルはフラットである必要はありません。オブジェクトをプロパティとして含めることができます)。
• ビューモデルで強く型付けされたビュー
• コントローラー: このコントローラーは、ビジネス ロジック (モデル、MVC の M) を使用して、アプリケーション フローを制御し、ビューのモデル ビューを作成して提供し、ユーザー アクションに反応します。
• UI ヘルパー: 通常、DRY 原則を満たすためにこのレイヤーを追加します。つまり、SelectList を準備する必要があり、それが多くのビューで使用される場合、このレイヤーで行い、必要なすべての場所から使用します。これには、計算、順序付け、または UI に密接に関連するものを含めることができるため、ビジネス レイヤー (モデル) には適合しません。これはビジネス層を使用し、ビューに固有のデータを提供します。

これらは、MVC の VC (ビューとコントローラー) を含む MVC の特定の重要な部分です。MVC (モデル) の M は、「通常どおり」実行できるビジネス ロジックです。つまり、MVC で使用するためにビジネス層で特別なことをする必要はありません。選択したテクノロジ (従来の DAL + BLL、WCF、WS、または必要なもの) を使用できます。

これは、LOB アプリケーションに適しています。もちろん、おもちゃのアプリケーションを作成している場合は、このすべてを忘れて、よりモノリシックなものを作成できます。しかし、これは、メンテナンスの必要性がほとんどない非常に小さなアプリケーションにのみお勧めします.

これらは、「ペット」を編集できるいくつかのレイヤーのオブジェクトの例です。

• ビジネス ロジック層:
  • PetService、ペットの読み取り、書き込み、検索、および変更に使用できるクラス (上記で説明したように、これがどのように実装されているかは問題ではありません)
• ビジネス エンティティ: ペットを管理するための BLL エンティティです。これは、POCO オブジェクトまたは DDD エンティティである可能性があります。
  • ペット - int Id、int PetTypeId、string Name...
• ビュー モデル: Pet プロパティと PetTypes のリストが含まれているため、ビューは PetTypeId のドロップダウン リストをレンダリングできます。
  • PetViewModel - ペット ThePet、SelectList PetTypes
• UI ヘルパー: PetTypes が 1 つまたは 2 つ以上のビューで使用される場合、PetUiHelper は、それを必要とするすべてのビューに対してこの選択リストを提供できます。
  • PetUiHelper - GetPetTypesList()
• ペット ビュー: PetViewModel の厳密に型指定されたビュー
  • Views\Pet\Edit.cshtml
• PetController: PetService を使用して、ビューとそのモデル ビューを作成します。
  • PetController - Edit(int id) --> 対応する PetViewModel を含む Edit ビューを返します。特定のモデル、PetViewModel、または Pet と Id などでユーザー入力を受け取る HttpPost Edit アクションも必要です。これは、何を編集しているかによって異なります。

最後に、DI の使用方法を知っている場合は、Unity.Mvc またはその他のオプションを使用して、コントローラーにビジネス サービスを挿入できます。

Answer 3

私が取り組んできたほとんどの MVC アプリは、このように階層化されていました

MVC プロジェクト: コントローラー、ビュー、およびモデルがありました。ビジネス ロジックはモデル内にあります。

データ アクセス レイヤー (永続レイヤー) : このプロジェクトでは ORM を使用します。（あなたの場合、エンティティフレームワーク）

データベース テーブルにマップされるクラスは、データ アクセス層ではなく、モデルに存在します。

Answer 4

Code First アプローチを使用してデータ アクセスを構築しているように思われる場合は、この広範な記事を掘り下げて、より多くの洞察を得ることができます。

http://ofps.oreilly.com/titles/9781449320317/ch_AdvancedData.html

Answer 5

そこにはレイヤーが多すぎる可能性があります。モデルにアクセスするためのクライアント アプリまたは別のプロジェクトを計画している場合を除き、ビジネス ロジックを含むモデルを LayeredProject MVC レイヤー自体から分離する理由はありません。MVC プロジェクトには、そのために使用できるモデル フォルダーが既にあります。ただし、MVC プロジェクトでは、「ViewModels」フォルダーを追加して、特にビュー関連 (DTO オブジェクトなど) に使用されるモデルを保持する必要があります。

このプロジェクトは、MVC プロジェクト ( RacoonBlog Project ) のフォルダー内で物事を単純に分離しておくための優れた簡単な方法を示しています。EF ではなく RavenDB を使用しますが、考え方は同じです。