C# で独自の IOC コンテナーを作成した人はいますか? それとも、Spring などのさまざまなフレームワークを使用する大多数の人々ですか。それぞれの長所と短所は何ですか?
12 に答える
自分で作成するのは良い練習ですが、最終的には既存のコンテナを使用することをお勧めします。15行のコードでこれから始めることができます。
誰かがC#で1つ書いています:http://ninject.org/。
これはオープンソースなので、コードを入手して、この人がどのようにそれを行ったかを確認できます。
特にUnity、 Ninject 、Spring.netなどの優れたオプションがたくさんあるため、車輪を再発明して自分で IoC コンテナーを実装しない非常に正当な理由がない限り。
これらの IoC コンテナーのいずれかへの依存関係を削除する必要がある場合、または削除したい場合は、 Common Service Locatorインターフェイスを試すことができます。
軽量で高性能な IoC コンテナーを探している場合は、Munqをチェックしてください。
James Kovacs は、このテーマに関する dnrTV のエピソードをここで紹介しています。こちらにも記事を書きました。ただし、記事の中で彼は、おそらく事前に構築されたものの1つを使用したいと思うだろうと述べています. それらには多くの多様なルックスがあるので。Ninject、StructureMap、Autofac は流暢なインターフェースを使用します。Spring、Castle Windsor、および Unity は、より XML 構成によって駆動されます。Castle Windsor は boo をインターフェイスとして使用することもできます。多くは、Unity から EntLib へ、またはキャッスル ウィンザーからモノレールへ、その他のキャッスル プロジェクトへのフックなど、他のフレームワークへのフックを持っています。
したがって、利用可能な IOC フレームワークによって提供されていないものが本当に必要な場合や必要でない場合は、そのうちの 1 つを使用してみませんか。
オートファックは優秀です。
私は 15 行未満を使用して自分で作成しました。ディクショナリへの拡張メソッドは 2 つだけです。
IOC コンテナーを書くのは難しくありません。これは、いくつかの潜在的な追加機能を備えた、適切に管理されたグローバル再帰ファクトリーです。ディクショナリ、リフレクション、デリゲートを使用して、単純なコンテナを登録および構築します...
本当の問題は、別の新しい IOC コンテナ フレームワークがなぜ、どのように利益をもたらすことができるのかということです。
ほとんどの場合、より多くのパフォーマンスが必要だと思いますか? 存在しない機能?しかし、ほとんどの場合、既存のフレームワークは必要なものだけで十分です。ただし、フレームワークがそれを使用することを強制するすべてのナンセンスに気付いていない場合は除きます。
ioc コンテナーのフレームワークのすべての実装に失望する力があり、アンチパターンのオーダーの機能を備えていますが、風変わりで信頼性の低い構文もあり、さらに悪いことに、強制されたカップリングの鉱石もあります。私はそれを経験することにしました。これが、私が独自の (非常に軽量な) IOC コンテナーをオープンソースとして作成した理由です。
ここで確認できます: Puresharp API .net 4.5.2+
Ayendeは、自分の IoC コンテナーを作成することについて、ブログ投稿Building an IoC container in 15 lines of codeにも書いていますが、彼も他の人と同じ意見だと思います。
オブジェクトの作成をデバッグしやすくする独自の IoC コンテナーを作成しました (コンテナー コードにアクセスできない場合でも)。オブジェクトが作成されたら、[ステップ イン] (F11) を押すと、オブジェクトを作成するコードが表示されます。完全なコードはここで見ることができます。