どの依存性注入ツールを使用する必要がありますか? [閉まっている]
質問
ユーザーインターフェイスのDependency InjectionツールにMicrosoft Unityを使用することを考えています。
Middle TierはすでにCastle Windsorを使用していますが、Microsoftに固執すべきだと考えています。
最も優れた依存性注入ツールとは何かを考えている人はいますか?
解決
IoC / DIを念頭に置いてシステムが設計されている場合、1つのコンテナに貼り付けることはそれほど重要ではありません。適切なアプローチを使用すると、今後IoCライブラリを簡単に変更できます。
そして、もちろん、コンテナは、広く使用されている一般的なシナリオ(ライフサイクル管理、適切なコンテナのネスト、XMLおよびコード設定、インターセプト、高速解決)をサポートするのに十分な柔軟性を提供する必要があります。
Castle(広く使用され、多くの統合ライブラリがある)とAutofac(軽量、高速、適切なコンテナネストがありますが、それほど広く使用されていない)を選択することをお勧めします
Hanselmanによる IoCコンテナーの包括的なリストがあります。
PS:Unityを使用したくない
他のヒント
最近、これらのうち6つを使用しました( Windsor 、 Unity 、 Spring.Net 、 Autofac 、 Ninject 、 StructureMap )を提供できますそれぞれの概要、選択基準、最終選択。
注:私たちのチームの1人が.NetポートがJavaバージョンから非常に貧弱であると考えたため、PicoContainer.Netは見ませんでした。 UnityはObjectBuilder2の上に構築されており、デフォルトでは優れた選択肢であると考えられていたため、ObjectBuilderも検討しませんでした。
まず、それらのすべてが多かれ少なかれすべて非常によく似ていると言えますが、それは実際にあなたに最適なものと特定の要件にかかっています。要件は次のとおりです。
要件
- コンストラクターベースのインジェクション(プロパティ、フィールド、またはメソッドのインジェクションを使用することをしない)
- プログラム可能な構成( not XML)
- コンテナ階層(アプリケーションごと、リクエストごと、セッションごとに1つ、コンポーネントのライフタイムスコープをコンテナに暗黙的にバインドします)
- コンポーネントライフタイム管理(一時的/シングルトンなどのより詳細なスコープ用)
- インターフェースから型または具象インスタンスへの注入(例:
ILogger-> typeof(FileLogger)
またはILogger-> new FileLogger()
) - 高度なコンポーネントの作成/ "creaton event mechanism" "事前/事後初期化用
- コンテナ上の
IDisposable
コンポーネントの正しい破棄 -
十分に文書化された、および/またはオンライン情報がすぐに利用可能
注:パフォーマンスは要件でしたが、このベンチマーク
テスト
各コンテナは、典型的なAsp.Net webformsプロジェクトで使用されていました(これがターゲットアプリケーションタイプであったため)。単一の単純なユーザーコントロールを持つ単一の単純なページを使用し、それぞれがベースページ/ベースコントロールからそれぞれ継承しています。 「リクエストごと」に BasePage
で1つのコンテナを使用しました。スコープコンテナと「アプリケーション」のglobal.asaxの1スコープし、それらを連鎖させて、両方のコンテナから依存関係を解決できるようにしました。
各Webアプリケーションは、依存関係、スコープタイプ(シングルトン/トランジェント)、およびマネージクラスとアンマネージクラス( IDisposable
が必要)のマルチレベルをシミュレートするドメインオブジェクトの不自然なセットを共有しました。 「トップレベル」依存関係コンポーネントは、 BasePage
のメソッドから手動で注入されました。
結果
Windsor-すべての基準を満たしており、良好なケース履歴、ブロガーコミュニティ、オンラインドキュメントがあります。使いやすく、おそらく事実上の選択です。工場設備による高度なコンポーネント作成。個別に作成されたコンテナのチェーンも許可されました。
Spring.Net-詳細で役に立たないドキュメントと、プログラムの構成がわかりにくい/簡単です。ジェネリックをサポートしませんでした。選択されていません
Ninject-わかりやすく明確なドキュメントがあり、使いやすい。コンテナ階層を除くすべての要件を満たす強力な機能セットなので、残念ながら選択されませんでした。
StructureMap-十分に文書化されていませんが、高度な機能セットはすべての要件を満たしていましたが、組み込み機能はありませんでした
これは、.NET IoCコンテナーを比較する優れた記事です。 http:// blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/
1年前に Autofac を使い始めて以来、振り返っていない。
私はAutofacのファンですが、WindsorとUnityの両方がうまく機能します(ただし、Windsorは結束よりも能力が高く、コードの帰属を必要としません)。ただし、システム内の単一のコンテナに固執する理由は、技術的ではない多くの理由があります。
動作するものを使用します。ほとんどは独自の機能を備えており、ほとんどすべてがUnityよりも機能が豊富です。統一が必要な場合は、それを使用できます。
Microsoftからのものであるという理由だけでMicrosoftの団結を使用することは、決定を下すための不十分な方法です。必要なものとその理由を考え、ニーズに合ったものを選択してください。
ただし、可能であれば、単一のコンテナに固執するという概念を再確認します。
Managed Extensibility Framework を使用しており、作業が非常に簡単であることがわかりました。 .NET 4に統合されました。
可能なIoCコンテナソリューションの1つで利用される特定のサブテクノロジーの経験と個人的な好みがない限り、それらはすべて正常に機能し、特に「キラー機能」を持つものは見当たりません。それは他の人からそれを際立たせます。 Unityは、おそらくP& P Enterprise Library 4.xを既に利用しているソリューションに最適です...
IoCコンテナベンチマーク-パフォーマンスの比較 20以上の製品のパフォーマンスと機能の比較表があり、それらを最新の状態に保ちます。
記事の結論:
SimpleInjector、Hiro、Funq、Munq、およびDynamoが最適です パフォーマンス、彼らは非常に高速です。それらを試してみてください!
特に単純なインジェクターは良い選択のようです。それは非常に速く、良い 文書化および傍受などの高度なシナリオもサポート 汎用デコレータ。