問題タブ [dependency-injection]

調べる価値のある C#/.NET 依存性注入フレームワークはどれですか? そして、それらの複雑さと速度について何と言えますか。

私は最近 StructureMap を使用しており、その経験を十分に楽しんでいます。ただし、すべてをインターフェイスで接続することに簡単に夢中になり、コンストラクターに大量のインターフェイスを取り込むクラスになってしまうことは理解できます。依存性注入フレームワークを使用している場合、これは実際には大きな問題ではありませんが、インターフェースを提供するためだけにインターフェースを提供する必要のない特定のプロパティが存在するように感じられます。

クラスにプロパティを追加するだけでなく、何をインターフェイスアウトするかについて、どこに線を引きますか?

Castle Windsorを使用して依存性注入を行っています。具体的には、現在DIによってロードされているインターフェイスにDALレイヤーを抽象化しました。

プロジェクトが開発およびデプロイされると、すべての.binファイルが同じ場所に配置されますが、Visual Studioで開発している間、依存関係が挿入されたプロジェクトの.binファイルをスタートアッププロジェクトのbinに取得する唯一の方法を確認できます。フォルダは、それをコピーするビルド後のイベントを持つか、ファイルをプルするためにDALプロジェクトへの手動参照を入れるかのいずれかです。

私はどちらの解決策にも完全にわくわくしているわけではないので、この問題を解決するための「標準的な」方法があるかどうか疑問に思いました。

マイナス面はありますか？私は今、それにほとんど依存していると感じています。プロジェクトが特定のサイズを超えると、標準パターンに対するアレルギー反応をほとんど感じ、すぐに依存性注入フレームワークで再配線します。

私が見つけた最大の問題は、それを学んでいる他の開発者にとって混乱を招く可能性があることです。

また、それが自分の使っている言語の一部になれば、もっと気分が良くなるでしょう。ただし、少なくともJavaの場合、非常に優れた非常に軽量なライブラリがいくつかあります.

考え？悪い経験？それとも気にするのをやめますか？

[編集] Re: 依存性注入自体の説明

曖昧でごめんなさい。マーティン・ファウラーは、おそらく私が今までできなかったよりもはるかにうまく説明しています...努力を無駄にする必要はありません.

偶然にも、これはそれについての 1 つのポイントを確認します。それは、それがまだ広く実践されておらず、チームで作業するときに全員がそれに慣れていない場合に障壁になる傾向があるということです.

ますます複雑化するエンタープライズサービスのシステムで依存関係を切り離すには、絶対にIoCコンテナを使用する必要があります。私が直面している問題は、構成（別名登録）に関連する問題です。現在、開発から本番、そしてその間の4つの異なる環境があります。これらの環境には、環境ごとにわずかに異なる多数の構成があります。ただし、現在考えられるすべてのケースで、コンポーネント間の依存関係は環境ごとに異なりません。ただし、何かを見逃したり、明らかに変更されたりする可能性があります。

したがって、最終的な質問は、IoCフレームワークを使用して同様の経験をした人はいますか？または、ある種の規則や簡略化された構成情報を通じて柔軟な登録を提供するフレームワークを他のフレームワークよりも推奨できる人はいますか？それでも流暢なインターフェースの恩恵を受けることができるのでしょうか、それともXMLに固執しているのでしょうか？XMLを避けたいのです。

編集：これは.Net環境であり、Windsor、Ninject、およびAutofacを見てきました。Autofacのラムダ式のサポートは他の方法とは少し異なるようですが、これらはすべて登録の両方の方法（流暢とXML）をサポートしているようです。誰かが同様のマルチデプロイメント環境でそれを使用しますか？

I've got a solution with several different projects in it, some are pure class libraries and some are web app projects. If I want my default types to be available to all projects, where should I put the config file for the container?

テストプロジェクトでは、依存性注入にCastleWindsorを使用しています。'Repository'クラスの1つにインスタンスを作成しようとしています。「自分のマシンでは正常に動作します」が、TFSでナイトリービルドを実行すると、テストで上記のクラスを読み込めません。

xml構成：

新しいビルドをキューに入れると、次のメッセージが表示されます。

クラスExample2008.Test.ActiveProductRepositoryTestのインスタンスを作成できません。エラー：System.Configuration.ConfigurationException：タイプ名Example2008.Repository.LALALALALA、Example2008.Repositoryが見つかりませんでした。

Castle.Windsor.Installer.DefaultComponentInstaller.ObtainType（String typeName）Castle.Windsor.Installer.DefaultComponentInstaller.SetUpComponents（IConfiguration [] configuration、IWindsorContainer container）Castle.Windsor.Installer.DefaultComponentInstaller.SetUp（IWindsorContainer container、IConfigurationStore store）Castle.Windsor .WindsorContainer.RunInstaller（）Castle.Windsor.WindsorContainer..ctor（IConfigurationInterpreterinterpreter）Example2008.Test.ActiveProductRepositoryTest..cctor（）in d：\ Code_Temp \ Example Project Nightly \ Sources \ Example2008.Test \ ProductRepositoryTest.cs：line 19

このメッセージから、私の構成は正しいようです（具象クラス「LALALALALA」をインスタンス化したいことがわかるので、xml構成は明らかに正しく赤くなっています）

依存関係も正しく設定されていると思います（ソリューションをクリーンアップして再構築しても、ローカルで機能するため）。

何かご意見は？

（ちなみに、VS2008、TFS 2008.Net 3.5、Castle 1.03を使用）

MEF（Managed Extensibility Framework）は、既存のIoC / DIコンテナーでは解決できない問題をどのように解決しますか？

私が取り組んでいるペットプロジェクトにキャッスルウィンザーを使用しています。新しいオブジェクトを作成するには、コード内のさまざまな場所で IoC コンテナーを呼び出す必要があることに気付き始めています。このコンテナーへの依存関係により、コードの保守が難しくなります。

この問題を解決するために私が使用した2つの解決策があります

オブジェクトを作成する必要があるアプリケーションの部分に挿入できるコンテナのラッパーとして抽象ファクトリを作成しようとしました。これは機能しますが、キャッスルが独自のコンテナーを依存関係として注入するのに苦労するため、いくつかの欠点があります。そのため、手動で行う必要があります。この種のことは、IoC コンテナーの目的全体を無効にします。

メインの applicationcontroller クラスを使用して IoC コンテナーをラップし、中央のファクトリー/リポジトリーとして機能させました。これは非常に成功しましたが、このクラスは大きくなりすぎて、中心的な神のオブジェクトのように振る舞い、他のほとんどすべてのオブジェクトがそれを参照しています。

どちらのソリューションも機能しますが、どちらにも欠点があります。他の人が同じ問題を抱えていて、より良い解決策を見つけているかどうか、私は興味があります.

編集 問題は、オブジェクト B に依存するオブジェクト A ではありません。ここでは、通常、コンストラクター注入を使用するだけで、すべてが機能します。時々、タイプ A のオブジェクトが、存続期間中に可変数のタイプ B の他のオブジェクトを作成する必要がある場合があります。これを行う方法がわかりません。

@ブレア・コンラッド: メンテナンスの問題は今のところ深刻ではありません。いくつかのクラスは、container.Resolve<> を呼び出すコンテナー オブジェクトに依存していました。また、インフラストラクチャと思われるものに応じてコードを作成したくありません。私はまだ試している途中なので、このプロジェクトで ninject から城に切り替えるときに、多くのコードを変更する必要があることに気付きました。

@花:うーん。私はあなたの拳のソリューションが好きです。私が試した両方のソリューションから機能するものを組み合わせています。私はまだオブジェクトについて考えすぎていて、インターフェイス/責任について十分に考えていなかったと思います。専用の工場を試してみましたが、コンテナを舞台裏で使用してオブジェクトを作成したいと思いますが、コンテナをきれいな方法でオブジェクトにDIする方法がわかりませんでした。

私は長年のWindows開発者であり、win32と初期のCOMに歯を食いしばっています。私は2001年から.NETを使用しているので、C＃とCLRにかなり精通しています。Stack Overflowに参加し始めるまで、CastleWindsorのことは聞いたことがありませんでした。Castle Windsorの「GettingStarted」ガイドを読みましたが、クリックされません。

この老犬に新しいトリックを教えて、CastleWindsorをエンタープライズアプリに統合する必要がある理由を教えてください。