14

私はEntity Framework 6データベースファーストを使用しています。プロジェクトを変換してオニオン アーキテクチャを実装し、関心の分離を改善しています。多くの記事を読み、多くのビデオを見てきましたが、ソリューションの構造を決定する際にいくつか問題がありました。

Core、Infrastructure、Web & Tests の 4 つのプロジェクトがあります。

私が学んだことから、.edmx ファイルは "Infrastructure" フォルダーの下に配置する必要があります。ただし、リポジトリと作業単位のパターンを使用して EF のデカップリングを支援し、依存性注入を使用することについても読んだことがあります。

これが言われていると：

  • モデル内のすべてのエンティティに対して、CORE の下にリポジトリ インターフェイスを作成する必要がありますか? もしそうなら、巨大なデータベースでこれをどのように維持しますか? 私は automapper を調べましたが、IEnumerables と IQueryables を提示する問題が見つかりましたが、これを実行する必要がある拡張機能が利用可能です。このルートをさらに深く試すことはできますが、最初に連絡を取りたいです。

  • 別の方法として、edmx をインフラストラクチャに残し、エンティティの .tt T4 ファイルを CORE に移動する必要がありますか? これは、密結合または適切な解決策を示していますか?

  • あなたが提供する提案で、一般的なリポジトリインターフェースはうまく機能しますか? それとも、EF6 は既にリポジトリと UoW パターンの問題を解決しているでしょうか?

私の質問をご覧いただきありがとうございます。代替の回答も提示してください。

ここで同様の投稿が見つかりましたが、回答はありませんでした: EF6 and Onion architecture - database first and without Repository pattern

4

2 に答える 2

10

データベースが最初にオニオン アーキテクチャを完全に除外するわけではありません (別名、ポートとアダプターまたはヘキサゴン アーキテクチャであるため、それらへの参照があれば同じものです) が、それは確かにより困難です。オニオン アーキテクチャとそれが可能にする関心の分離は、ドメイン駆動型の設計に非常にうまく適合します ( Pluralsight でこのテーマに関する私のビデオを既にいくつか見たことがあると Twitter で述べたと思います)。

EDMX をコア プロジェクトまたは Web プロジェクトに配置することは絶対に避けてください。インフラストラクチャはそのための適切な場所です。その時点で、データベース ファーストを使用すると、インフラストラクチャに EF エンティティが作成されます。ただし、ビジネス オブジェクト/ドメイン エンティティを Core に配置する必要があります。この時点で、このパスを続行する場合、基本的に 2 つのオプションがあります。

1) コアで POCO エンティティを使用できるように、データベース ファーストからコード ファーストに (おそらくツールを使用して) 切り替えます。

2) おそらく AutoMapper のようなものを使用して、インフラストラクチャ エンティティとコア オブジェクトの間を行ったり来たりする。EF が POCO エンティティをサポートする前は、これを使用するときに私が従ったアプローチであり、コア オブジェクトのみを処理し、内部的に EF 固有のエンティティにマップするリポジトリを作成していました。

リポジトリと作業単位に関するあなたの質問に関しては、SO や他の場所で、これについてすでに多くのことが書かれています。確かに汎用リポジトリの実装を使用して、多数のエンティティへの簡単な CRUD アクセスを可能にすることができます。これは、シナリオを進めるための迅速な方法のように思えます。ただし、私の一般的な推奨事項は、ビジネス オブジェクトにアクセスする手段として一般的なリポジトリを使用することを避け、代わりに Aggregate を使用することです (DDD または Pluralsight の Julie Lerman による私の DDD コースを参照してください)。複雑なビジネス エンティティを CRUD 操作から分離することもでき、それが保証されている場合にのみ集計アプローチに従うことができます。このアプローチから得られる利点は、オブジェクトへのアクセス方法を制限できることです。

アプリケーションごとに 1 つの dbcontext しか持てないとは思わないでください。グリーン フィールド アプリケーションから開始するのではなく、時間の経過とともにこの設計を進化させているようです。そのために、.edmx ファイルと、おそらく CRUD 目的の汎用リポジトリを保持できますが、POCO エンティティ、関心の分離、テスト容易性の向上などを保証する特定の一連の操作のために、最初に新しいコード dbcontext を作成します。時間の経過とともに、これを使用するために重要なコードの大部分をシフトできますが、既存の dbcontext を維持しながら、現在の機能を失うことはありません。

于 2014-06-24T20:39:45.303 に答える
1

DDD プロジェクトでエンティティ フレームワーク 6.1 を使用しています。Onion Architecture を実行する場合、コードは最初は非常にうまく機能します。

私のプロジェクトでは、リポジトリをドメイン モデルから完全に分離しました。アプリケーション サービスは、リポジトリを使用して集計をデータベースから読み込み、集計をデータベースに保持します。したがって、ドメイン (コア) にはリポジトリ インターフェイスはありません。

別のアセンブリで T4 を使用して POCO を生成する 2 番目のオプションは良い考えです。ドメイン モデル (コア) は永続性を無視する必要があることに注意してください。

汎用リポジトリは集約レベルの操作を実施するのに適していますが、すべての集約がこれらの汎用リポジトリ操作のすべてを必要とするわけではないという理由だけで、特定のリポジトリをより使用することを好みます。

http://codingcraft.wordpress.com/

于 2014-08-24T04:38:21.663 に答える