7

標準的なアプローチに従う 3 層の .NET サービス アプリがあります。

Frontend -> Object Model / Business Logic -> Data Access

私は途中で依存性注入について学ぼうとしていますが、これまでのところ、(Autofac を使用して) 素晴らしいことがわかりました。3 つの層のそれぞれは、さまざまなオブジェクトを作成する必要があり、場合によっては追加の構成などが必要になります。これを解決するには DI コンテナーが理想的であるように思われますが、システムの残りの部分との関係で、DI コンテナーがどこに存在するべきかを確認するのにいくつか問題があります。

現在、フロントエンドに DI コンテナーを構成するクラスがあります。それは基本的にコードの大きな束ですcontainer.Register<SomeType>()。

問題は、3 つの層すべてに対してコンテナーを構成しているため、データ アクセス レイヤーに関するかなり侵略的な知識が必要なことです。アプリを層に分割するポイントは、この正確な状況を回避することであるため、そのような知識を備えたフロントエンドにコードがあると、頭の中で警鐘が鳴らされます。
これは、データ アクセス レイヤーが単なる SQL サーバーではなく、多数の複雑な COM 相互運用機能と P/Invoke 呼び出しで構成されているため、DI に大きな影響を与えるという事実によっても悪化します。構成。

私はそれを分割することを考えました - おそらく層ごとに1つのコンテナーを持つか、グローバルDIコンテナーと通信して独自のビットを登録する「セットアップ」クラスを各層に持つことですが、それが原因かどうかはわかりません解決するよりも多くの問題...

多層アプリで DI を使用した経験を誰かが共有できれば、本当にありがたいです。

ありがとう、オリオン。

4

1 に答える 1

3

これは、3 つの層 (物理的な分離) があるか、またはすべての論理レイヤーが一緒に展開されているかによって異なります。フロントエンドが BL とは別であり、Web サービスまたは WCF を介して通信する場合、フロントエンドとバックエンドは別々のプロセスまたは別々のマシンで実行されているため、独自のコンテナーが必要です。コンテナーは、独自のコンポーネントと「次の」レイヤーのインターフェイスのみを登録します。

一方、すべてのレイヤーが同じプロセスで実行されている場合は、コンテナーは 1 つだけにする必要があります。コンテナーは、Web アプリの global.asax のようなアプリケーションの開始点で初期化およびホストされます。

コンテナー ホストがシステムのさまざまな部分の多くを認識しているという問題は、クラスを 1 つずつ登録するのではなく、すべての型をアセンブリに登録することで解決できます。そうすれば、コンテナーを構成するためだけに、ソリューション内のすべてのアセンブリへの強い参照は必要ありません。Castle Winsdor でそれを行う方法の例:

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));
于 2009-02-11T19:23:07.273 に答える