このトピックについて多くの議論が見られますが、これに関する非常に詳細な回答が見つかりません。あちらこちらに何を置けばいいのか知りたいです。
IRepositoryインターフェースはどこに置くべきですか？DataAccess または別のプロジェクトで「リポジトリ」と言いますか? IRepository<> のように拡張する他の抽象リポジトリはどう ICustomerRepository : IRepository ですか? それらは同じプロジェクトに常駐しますか? の具体的な実装はどうですか？CustomerRepository : BaseRepository, ICustomerRepository
そして私のPOCO、どこに置けばいいですか??
UnitOfWork とサービス層?
PS: すべてのサービスに UnitOfWork だけを含めて、任意のリポジトリを呼び出すことはできますか? そこに欠点はありますか？または、なぜサービスの UnitOfWork よりもリポジトリを使用したいのでしょうか?
明確な答えではありませんが、正しい方向に進むことを願っています
ORM を使用する場合は、フレームワークがリポジトリと UOW を処理します。
1) UI - 2) サービス エージェント - 3) サービス レイヤー - 4) ドメイン レイヤー - 5) リポジトリから開始できるレイヤーは次のとおりです。
クライアントからサービスへ 1 つのクライアントのみがサービスを使用する場合、サービス層は不要です。UIと同じプロセスで実行されるFacadeレイヤーで十分かもしれません。複数のクライアントアプリケーションをサポートする必要がある場合は、比較的少ない労力でサービスを分離するようにリファクタリングできます。すべてのサービス呼び出しをサービス エージェント (プロキシ) に抽象化します。UI からサービスへのすべての通信は、エージェントを介して行われます。
サーバー側の mvc フレームワーク (例: asp.net mvc) のようなものを使用している場合は、画面ごとにビューモデルを検討することをお勧めします。ほとんどの画面には異なるドメイン モデル (注文の詳細 + 配送情報 + 顧客の詳細が 1 つの画面に表示される) からのデータが含まれているため、ビュー モデルはすべてのデータを画面固有に統合します。この場合、(.net) 自動マッパーを見て、DTO (サービスからのデータ) とビュー モデルの間のマッピングを行うか、独自の軽量マッパーを構築します。クライアント側の MVC を UI (例: Angular) に使用する予定の場合は、ビュー モデルを明示的に設計する必要はありません。サービスから得られるものはすべて、UI のモデルになります。
Service to backend Service/facade レイヤー - これにより、ドメイン モデルで適切なメソッドが呼び出されます。すべての CRUD のドメイン モデル呼び出しリポジトリから、POCO を設計します (ドメインをモデル化します)。内部リポジトリは ORM を使用できます。なんらかの理由で ORM を使用していない場合は、データベースやその他のデータ ストアからドメイン モデルにデータをマッピングするための汎用コードを作成する必要がある場合があります。
ドメイン層、リポジトリ、およびサービス層のすべてのクラスのクラス インターフェイスを定義します (とにかく、フレームワークはサービスのインターフェイスを使用することを強制します)。サービス/ファサードで大まかなインターフェイスを設計することを忘れないでください。そうしないと、UI とサービス間の呼び出しが多すぎます。
レイヤーごとに個別のプロジェクトを作成し、1 つの平均的な複雑さのユース ケースを取り上げ、すべてのレイヤー、エンティティ タイプ (ビュー モデル、dto、ドメイン モデル)、マッパー (Viewmodel-dto、dto-domain モデル) を利用してエンド ツー エンドの実装を開始します。 . インターフェイスはクライアントに属しているため、すべてのインターフェイスを具象クラスプロジェクトとは別のプロジェクトに保持すると言えます。これにより、クライアントが具体的な実装プロジェクトに直接依存することがなくなります。IOC コンテナーを識別し、それを使用してクライアントに依存関係を注入します。例: DI を使用して、ドメイン モデルをサービス層のクラスに注入します。すべてのレイヤーに具体的な実装を挿入するように DI を構成します (サービスは DI を使用してドメイン モデルを取得し、ドメイン モデルは DI を使用してリポジトリを取得します)。DIを使用すると、インターフェイスに対してコードを作成できます。これは良いことです。重要なことは、インターフェイス、クラス、メソッド、
1 つのユース ケースを完了すると、あなたとあなたのチームは、ドメイン モデルの学習/設計/議論により多くの労力を費やすことになります (Eric Evans によるドメイン駆動設計を読む - ドメイン駆動設計の著者/作成者)。非常に多くのことがあり、どこからどのように開始するかを考えるのは非常に混乱する可能性があります. 各レイヤーのプロジェクトから始めると言ったように、リファクタリングするたびに追加/削除し、頻繁にリファクタリングします。
プロジェクトはかなり複雑だと思います。
私は数ヶ月前に同じ質問をしました。最新の .NET ソリューション アーキテクチャの決定的なガイドを実際に見つけたことはありません。その時点で、私のウィッシュリストには次のものが含まれていました。
階層化されたアーキテクチャ
依存性注入
汎用リポジトリ
モッキングによる単体テスト
そのため、各トピックについて個別に Web を調べ、さまざまなブログ投稿や記事から少しずつ借りてきて、多かれ少なかれ必要なものを手に入れました。
「asp.net リポジトリ パターン」と「asp.net mvc ソリューション構造」を検索すると、多くのスタック オーバーフロー ヒットが得られます。ディスカッションの一部を読んで、好きなアイデアを使用してください。
次のリンクをたどることができ、とても役に立ちます。
アーキテクチャの作成/セットアップ方法に関する回答を参照してください
それが完璧だとは言いませんが、それはあなたにスタートを与えます.