MVC アプリで UnitOfWork/Service Layer/Repository/EF4 w/POCO 設計を使用しています。
これまでのところ、私はこれを持っています:
1) MVC Web アプリ (Project.dll)
2) サービス層 (Project.Data.Services.dll)
3) リポジトリ層 (Project.Data.Repositories.dll)
4) POCOS (Project.Data.Domain.dll)
5) EF4/コンテキスト レイヤー (Project.Data.dll)
各レイヤーは、その下のレイヤーと Project.Data.Domain (POCO クラス) のみを参照します。
現在、Project.Data.dll に UnitOfWork Interface/Base がありますが、すべてのレイヤーがそれを参照する必要があります。それは設計が悪いのでしょうか？もしそうなら、それはどこに住んでいますか？
依存性注入を使用している方が良いと思います。この素晴らしい投稿をご覧ください: http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx
それはただの意見です。
ドメイン オブジェクトはビジネスの一部です。コンテキストとリポジトリについても同じです。
実際、私が言いたいのは、OR/M はリレーショナル データベースやその他の種類のストアに対する抽象化であるため、これらはオブジェクト指向ストアとして機能できるということです。
つまり、OR/M は、最新のソフトウェア ソリューションのデータ レイヤーを破棄します。
リポジトリ、ドメイン コンテキスト、ドメイン オブジェクトは、ビジネス レイヤーの一部です。
作業単位はソフトウェア設計パターンであり、データベースやデータ層を操作するだけでなく、ネットワーク化されたトランザクションなど、より多くのものを管理できます。これは、「YourCompany.YourProject.Patterns.UnitOfWork」などの名前空間に含めることをお勧めします。
サービスはデータとは何の関係もありません。「YourCompany.YourProject.Services」名前空間を提案したいと思います。
もう1つのポイントは、層や層を介してデータを渡す場合でも、どこでも使用しているため、POCOがDTOとしても機能しているように見えることです。これはネイキッド オブジェクトの実装などでは問題ない可能性がありますが、ドメイン オブジェクトを DTO として使用するという事実に注意を払う必要があります。ドメイン オブジェクトには、プロパティ、情報、動作、または非表示のメンバーをプロキシする OR/M が含まれている可能性があるためです。オブジェクトの重み - メモリ使用量 - に影響します。
最後のパラグラフの事実を踏まえて、ビジネス上の任意のレイヤーで DTO を使用することをお勧めします。これにより、サービスの利用者が正常に動作するために必要な特定の範囲のプロパティを持つ DTO がサービスから返されます。
DTO、パターンの実装、およびソリューションのすべてのプロジェクトで共有されるそのようなものは、「YourProject.Shared」と呼ばれるプロジェクトに存在する必要があり、このアセンブリはレイヤーを参照してはなりません。レイヤーニュートラルのままである必要があるため、どこでも参照できます無駄な依存関係を強制しません。
さて、これは私の意見であり、私のプロジェクトでの作業方法です。
https://github.com/sharparchitecture/Sharp-Architectureをご覧ください。あなたのように階層化された Northwind の例があります。UnitOfWork の実装が表示されます。
他のレイヤーがデータ プロジェクトを参照しないようにする場合はIUnitOfWork、別のプロジェクトに分離し、制御コンテナーの反転で依存性注入を使用する必要があります。