オプション1:
最初に、コアドメインのAPIとして機能するサービスレイヤーを呼び出して、ドメインオブジェクトまたはドメインオブジェクトのリストを取得し、それらをアセンブラーに渡して、ビューに必要なDTOを構築しました。 。この方法で私が抱えている問題は、ドメインオブジェクトが大きく、DTOに必要ないくつかのフィールドをコピーするためだけにオブジェクト全体をロードしたくない場合です(つまり、要約エンティティのリストを表示します)。
オプション2:
次に使用した方法は、リポジトリを(読み取り専用の目的で)アセンブラーに接続することで、DTOで必要なフィールドについてのみデータベースにクエリを実行できるようにしました。また、DTOを取得し、それを更新およびエンティティーに使用する必要がある場合にも、このリポジトリーを使用できます。たとえば、エンティティで更新する必要のあるDTOのwill値がアセンブラに入り、アセンブラがリポジトリからエンティティを検索して、DTOからの情報をエンティティにオーバーレイし、エンティティを返します。次に、コントローラーはサービスレイヤーを呼び出して、アセンブラが返したエンティティを保存します。
オプション3:
リポジトリを直接コントローラーに配線することはできますが、サービスレイヤーがトランザクションとセキュリティを処理する必要があるため、コントローラーでリポジトリを公開することについて何かが間違っているように見えますが、アセンブラーにリポジトリを配置すると、基本的には同じこと。
どんな考えでも大歓迎です。私は長所と短所、および他の人にとって何がうまくいったかを理解したいだけです。
OK。問題1:エンティティからDTOを取得する:
エンティティはデータを公開できるため、プロパティにアクセスしてDTOオブジェクトをインスタンス化するか、エンティティを直接シリアル化できます
問題2:DTOのエンティティ:
設定するプロパティのリストを取得するコンストラクタメソッドは、DTOのプロパティを使用して呼び出すことができます。
問題3:サマリー情報のみが必要な場合の大きなエンティティ
リポジトリから取得できる新しいサマリーオブジェクトを作成します。注意:一般的なORMを公開するのではなく、Repo.GetMyObjectById(string id)などのメソッドを使用して、厳密に型指定されたリポジトリを作成することをお勧めします。
問題4:このすべてを調整する場所。
私の推奨は、ホスティングサービス/アプリ/ウェブサイトの1レベル下にサービスクラスを設けることです。
これは、リポジトリのDTOとエンティティにアクセスでき、そのメソッドはアプリケーションのコントローラー/サービス呼び出しにマップされるため、最上位レベルでコードを必要とせず、同じサービスを複数の方法でホストできます。
リポジトリへのアクセス権を付与することは、必要なクエリを実行するのではなく、エンティティを廃棄するためにのみ使用できる場合は問題になりません。
このアセンブリ/オーケストレーションロジックをエンティティ内に配置することは、エンティティを他の目的で再利用する必要があるため、通常は不適切です。
このトップレベルのサービスは非常に軽いはずです。ただ、これらのオブジェクトを取得し、このメソッドを呼び出し、結果/ DTO /ビューモデルを作成して返します
とても軽いので、レイヤーをスキップしてコードをコントローラーに配置すると、大した問題にはなりません。しかし、ホスティングレイヤーを変更してテストなどを支援すれば、時間を節約できます。