4

私のプロジェクトは次のように構成されています

  • ASP.NET MVC 3 WebApp
  • Domain.Core-インターフェース[ライブラリ]
  • Domain.Core.Entity-エンティティ[ライブラリ]
  • Infrastructure.Core-インターフェースの実装[ライブラリ]
  • Infrastructure.IoC-制御の反転を実現する手段としてUnityを使用[ライブラリ]

窮状は次のとおりです。

次のように、Domain.Coreのインターフェイスにジェネリックメソッドを追加すると、Infrastructure.IoCプロジェクトのDomain.Core.Entityへの参照を追加するように求めるコンパイルエラーが発生します。

T Get<T>(int Id) where T : EntityBase, new();

Tは、EntityBaseから継承するクラスEntityBaseまたはBlog、またはすべてEntityBaseから継承する他のいくつかのエンティティにすることができます。提供される子クラスに基づいてエンティティを返すという考え方は、EntityBaseを実装するすべてのクラスに必要なデフォルトのデータが子クラスにロードされるようにすることです。

したがって、問題は2つあります。

  1. IoCプロジェクトでDomain.Core.Entityプロジェクトを参照せず、物事をクリーンに保つ方がよいでしょうか。

  2. 参照のクリーンさを濁さずに、上記のようなことをどのように達成できますか？

ありがとうございました。

注：このトピックを検索するためにここでいくつかの質問を調べましたが、何も表示されませんでした。表示された場合はお知らせください。この質問を削除します。

4

2 に答える 2

4

依存性注入では、さまざまな共同作業者すべてを構成する責任を持つ単一のコンポーネントを持つことが最善です。これは、ナット・プライスのサードパーティコネクトの概念のサードパーティ、または私がコンポジションルートと呼んでいるものです。上で概説したアーキテクチャでは、この責任はInfrastructure.IoCにあるように思われるため、この構造を考えると、Infrastructure.IoCからDomain.Core.Entityへの参照を追加しても問題はありません。そうではありませんでした。

ただし、全体的なフィードバックとして、別個のInfrastructure.IoCライブラリを使用することで実際にどのようなメリットが得られるかを検討する価値があると思います。そのアプリケーション（ASP.NET MVCアプリケーション）のエントリポイントには、Infrastructure.IoCへの参照が必要です。この場合も、ライブラリを構成するには、すべてのライブラリへの参照が必要です。したがって、ASP.NET MVCアプリケーションは、他のすべてのライブラリへの間接参照を持つことになり、これら2つをマージすることもできます。

（技術的には、XML構成や設定より規約などの遅延バインディングメカニズムに依存することで、さまざまなライブラリを分離できますが、Infrastructure.IoCの概念的な責任は変わりません。）

詳細については、次の回答をお読みください。Ioc / DI-エントリアプリケーションですべてのレイヤー/アセンブリを参照する必要があるのはなぜですか？

于 2012-04-22T08:33:11.107 に答える
3

Domain.CoreをDomain.Core.Entityから分割するのはなぜですか？そして、なぜInfrastructure.CoreをInfrastructure.IoCから分割するのですか？

私はあなたが3つのプロジェクト構造で逃げることができると思います：

  1. ドメイン-他の2つのプロジェクトへの依存関係はありません。エンティティとインターフェースが含まれる場合があります。
  2. インフラストラクチャ-インターフェイスの実装とUnityコンテナが含まれています。ドメインプロジェクトのみに依存します。
  3. MVC-ドメインとインフラストラクチャの両方に依存します。

インターフェイスではなく具象クラスに対するプログラミングが心配な場合は、インフラストラクチャプロジェクトのクラスに別の名前空間を付けてください。その場合、その名前空間を使用する必要があるのは、たとえあったとしても、おそらく2、3回（Global.asaxまたはbootstrapperで）する必要があります。

このようにして、どのプロジェクトが何に依存しているかが非常に明確になります。Unityを使用しているので、これはタマネギアーキテクチャの形式です。後でインフラストラクチャまたはドメインを複数のプロジェクトに分割する必要があることがわかった場合は、リファクタリングできます。

IMO、依存関係は、ドメインプロジェクトにSystem.Web.MvcやMicrosoft.Practices.Unityなどの参照がある場合にのみ、濁ったり汚れたりします。マークが彼の答えで言っているように、あなたの「タマネギ」の外側の層は内側の層に依存します、それを避けるためにあなたができることはあまりありません。ただし、UIでの使用方法の詳細をできるだけ避けて、ドメインをコアビジネスに集中させるようにしてください。

于 2012-04-21T21:50:52.637 に答える