2

Unity IoC フレームワークを使用しておりBootstrapper.cs、ホスト MVC レイヤーにすべてのコンポーネントを登録するためのクラスがあります。ただし、私のアーキテクチャでは、MVC レイヤーの下に「サービス」レイヤーがあり、これも DI を使用し、そこにリポジトリ インターフェイスが注入されています (リポジトリ インターフェイスは MVC レイヤーでは使用されません。サービス レイヤー インターフェイスがコントローラーに注入されています)。 .

したがって、私の質問は次のとおりです。アプリ全体のMVC / UIレイヤーの具体的なタイプにリポジトリインターフェイスを登録できますか、それともUnityへの別の参照を追加Bootstrapper.csして、「サービス」レイヤーに別のクラスを作成してインターフェイスを定義しますかその特定のレイヤーが使用するタイプ？

答えがUIレイヤーにインターフェースを登録できるというものであっても、一般的な慣行も知りたいです。そのタイプを MVC/UI レイヤーに登録するのが気に入らないのは、登録を行うためだけにリポジトリ レイヤーへの参照を追加する必要があることです。そのレイヤーで使用されていないことを知っていても。サービス層で使用されます。

ありがとう！

4

4 に答える 4

6

各アプリケーションには、アプリケーションを構成する場所である独自のComposition Rootが必要です (詳細については、この回答を参照してください)。

コンテキストにもよりますが、一般的に言えば、コンテナ構成をレイヤー間で分割すると、レイヤーの構成について決定を下すのはレイヤーに近すぎるため、一般的なビューが失われる可能性があります。

たとえば、ビジネス ロジック層の 1 つで、サービスを登録しています。

container.RegisterType<ISercice1, MyImplementation1>(new PerThreadLifetime())

しかし、Web アプリケーションでそのレイヤーを使用する場合、PerSession または PerRequest のライフタイムの方がより良いライフタイムになると判断できます。この決定は 1 か所だけで行う必要があり、複数のレイヤーにまたがってはなりません。

于 2013-01-25T07:46:14.907 に答える
3

私はあなたの質問をひっくり返します。

クラス ライブラリに Unity への参照を追加すると、使用しているフレームワークに依存関係が追加されます。それはあなたが達成しようとしていることとは正反対です。

クラスが必要とする唯一の適応は、コンストラクターをサポートするか、インターフェイスでパブリック プロパティを使用することです。それでおしまい！

したがって、アプリケーションのエントリ ポイントはすべての「ブートストラップ」を実行する必要があります。エントリ ポイントは、さまざまなアプリケーションやさまざまなテスト プロジェクトである可能性があることに注意してください。それらには、さまざまな構成とモック シナリオが含まれる可能性があります。

bootstrap.cs が大きくなった場合は、読みやすくするために小さなパーツに分割できます。しかし、クラスがブートストラップ/moqed/注入されているという事実と、何によってクラスが認識されているかという考えを拒否します。

再利用を検討します。現在のライブラリは Unity を使用しています。これらは、StructureMap を使用するプロジェクトで使用できます。または、なぜNinjectしないのですか。

于 2013-01-24T22:41:51.427 に答える
2

要するに、はい、構成をプロセスの最上位に保持するか、各モジュールにローカライズすることが可能です。ただし、すべての依存関係は、プロセス内のオブジェクト グラフ全体に対して解決する必要があります。

各モジュール (アセンブリ) に構成を保持することで構成をローカライズすることは、多くの場合、良い考えです。これは、サービス レイヤーが独自の構成を担当できるようにするためです。この質問に対する私の答え、私見は良い習慣です。

于 2013-01-24T22:16:09.507 に答える