1

アプリケーションのソリューション構造を設計しています。ドメイン駆動設計を使用する予定です。Asp.net MVC およびエンティティ フレームワーク。いくつかの分野であなたの意見が必要です。

データ アクセスは最初にエンティティ フレームワーク コードを使用して設計されます リポジトリは EF Data Access の上に構築されます ドメイン モデルはリポジトリの上にドメイン モデルを使用して設計されます アプリケーション サービスは Damain 層の上に構築されます UI はアプリケーション サービスの上に開発されます

流れは

UI (コントローラー) --> アプリケーション サービス --> ドメイン層 --> リポジトリ --> データ アクセス --> データベース。

レイヤー間でデータを共有する方法がよくわかりません。

マイ ドメイン モデルは、リポジトリ、データ アクセス、およびドメイン レイヤー間でデータを共有するために使用できます。Daomin Layert から Application Service および Application Service から UI にデータを渡す方法を考えています。私はDTOを使用できますが、いくつかのモデルがすでにドメインモデルにあり、UIでモデルを表示しているため、それが良いオプションであるかどうかはわかりません。

4

2 に答える 2

0

説明したフローを考慮して、コントローラーによってインスタンス化されるビューモデルを UI レイヤーに作成します。ビュー モデルは、ビューがバインドされる単純なオブジェクトです。これは、 namkha87によって指摘された問題に対処するために、基礎となるドメイン モデルから分離する必要があります。

データ アクセス レイヤーに関しては、ドメイン オブジェクト自体をオブジェクト リレーショナル マッピングに使用できます。これは EF で許可されているためです。ここでは、中間 DTO は必要ありません。

考慮すべきもう1つのことは、クエリに使用されるモデルを、呼び出し動作に使用されるモデルから分離することです。このようにして、アプリケーション サービスが動作ドメイン オブジェクトを公開せず、read-modelsのみを公開するようにすることができます。アプリケーション サービスがドメイン オブジェクトを外側の層に公開する場合の問題は、それらの外側の層がこれらのオブジェクトの動作を呼び出せるようになり、結果が未定義になることです。動作のない読み取り専用オブジェクトのみを返す場合、これは問題になりません。返されるデータについては、UI レイヤーでドメイン オブジェクトを直接作成しないでください。エンティティと単純なデータを区別する必要があります。

于 2013-04-02T00:23:44.023 に答える