3

.NETスペースの多くの人々がCastleWindsorを手に入れ、プロジェクトに実装しています。この1年間、IoCコンテナーが一般的な「ベストプラクティス」として扱われる理由を理解するのに苦労していました。ウィンザーの理由などについての要約と簡単な説明をたくさん読みましたが、それらの最後の1つは確かに抽象的であり、私が触れたほとんどのプロジェクトでは実用的ではないようですが、最近はウィンザーを使用する多くのプロジェクトに出くわしましたが、その理由はわかりません。

C＃/。NETは本質的に、インターフェイスベースのコーディング、抽象オブジェクト、デリゲート、およびイベントをサポートします。コア言語から直接IoCを実装し、Reflectionなどを使用して、IoCコンテナライブラリに頼ることなく、既知のインターフェイスを実装する未知のインスタンスをインスタンス化できます。

YAGNI / AYGNI（Are You Going To Need It？）を適用すると、ウィンザーが使いすぎたように感じます。IoCコンテナーの利点は確かにわかりますが、これらの利点には、追加の依存関係とメタデータ（コアコードで呼び出されるIoCコンテナー固有の属性とメソッド、いたるところに散在する.configファイル、app.config / web.config）が犠牲になると思います。バインディングタグでいっぱいになり、.configファイルの編集が難しくなるなど）ので、トレードオフを理解しようとしています。

とは言うものの、私はWindsorや他のIoCコンテナライブラリを使用したプロジェクトに深く関わったことがないので、これらすべての観察/無知に関する発言をしている可能性を受け入れています。私が本当に必要としているのは、IoCコンテナライブラリが使用された「平均的な」または「典型的な」プロジェクトを誰かがデモンストレーションすることです。依存関係とメタデータを使用します。

誰かが私を埋めるブログ投稿、記事、または本を知っているなら、それは素晴らしいでしょう。

（私は酒を主張するために議論しているのではありませんが、IoCコンテナについて自分自身を教育する必要があるかどうかについて本当に教育を受けたいので）。

4

4 に答える 4

2

私は Castle-windsor に精通しておらず、IoC の専門家でもないため、あなたの質問に対する直接的な回答ではありませんが、Spring の Java バージョンでの経験から、それはわかります (私は Spring について話しているのです)。ここでは、castle-windsor には当てはまらない可能性があります) 依存性注入の部分だけでなく、フレームワーク自体も優れています: 宣言型トランザクション管理、組み込みセキュリティ フレームワーク、ORM サポート、組み込み MVC Web フレームワーク、RMI、Web サービス、電子メール、AOP など。すべてが IoC と適切に統合されており、フレームワークはほとんどの典型的なシナリオで実際に多くの作業を行います。

そして、アノテーション + IDE サポート (例: Spring の IntelliJ IDEA) による自動配線により、構成ファイルの問題が軽減されると思います。

Castle-windsor が IoC コンテナー以外のものであるかどうかはわかりませんが、もしそうなら、フレームワークとしての機能の豊富さという点で、まだ存在していないだけかもしれません。

于 2008-11-19T19:56:21.327 に答える
2

この質問に対する答えが欲しいようです

あなたが言うようにシステムのセットアップが難しい場合は、システムを維持することにあまり価値がないことは明らかです。これは、新しいテクノロジーを使用する際に心に留めておくべき重要なことです。この要因だけで、古い退屈なものがはるかに優れている場合があります。

Castle Windsor はリフレクション自体を使用するため、とにかくやりたいように処理するためのラッパーです。CW よりも使いやすいシステムを開発できるのであれば、最初の起動時間にコストがかかるとしても、そうするべきです。そのコストは、そもそも CW の学習曲線によって相殺されるため、車輪を再発明するようなものではありません。

彼らは、IoC は小規模なプロジェクトには適していないと言っていますが、

また、プロジェクトのサイズと複雑さによっては、IoC コンテナーが過剰になる可能性があります。中規模から大規模のプロジェクトで使用することをお勧めします。

于 2008-11-19T19:57:07.300 に答える
1

IoC コンテナーがすべての場合に適しているとは限りません。しかし、それは間違いなく可能です。依存関係の処理に依存関係の挿入またはサービス ロケーターを使用する場合は、とにかく長い道のりを歩んできましたが、IoC コンテナーを使用すると自動的に処理を実行したり、より高度なシナリオをサポートしたりできます。

私はかなり前にブログ投稿でそれを自分で定義しようとしました:

制御の反転 (IoC) コンテナーは、非侵襲的な構成可能なインテリジェント ファクトリ コンポーネントです。

この定義を部分に分割すると、次のようになります。

  • ファクトリ。オブジェクトの作成を担当するためです。

  • 依存関係を理解し​​、再帰的に作成するため、インテリジェントです。

  • コードまたは構成ファイルを使用して使用法を構成できるため、構成可能です。

  • 使用されるオブジェクトはコンテナについて知る必要がないため、非侵襲的です。

    -

依存性注入またはサービス ロケーター パターンで適切に使用すると、非常に便利な利点が得られます。Winsor のような外部コンテナーを使用する必要は必ずしもありませんが、追加の利点が得られます。

新しいオブジェクトをインスタンス化するコードをはるかに少なく記述できます。また、より複雑なオブジェクト階層について考える場合、IoC コンテナーはチェーン全体を自動的に作成するのに役立ちます。それは非常に強力です。

テスト中にオブジェクトのモック バージョンを問題なく簡単に追加できます (DI や SL を使用している場合)。たとえば、自分用のサービスロケーターを作成すると、これも解決されます。

コンストラクターに挿入する依存関係を変更しても、多くのコードをリファクタリングする必要があるとは限りません。

1 つのソース (デコレーター、インターセプター、プロキシー) を介して依存関係をトンネリングすることでさまざまな利点が得られ、オブジェクトのライフスタイルを処理することもできます。Windsor のようなコンテナーを使用すると、いくつかの難しいことを非常にシンプルに実行できます。結合はほとんどありません。

たとえばNHibernateとのスムーズな統合のために、施設の概念を引き出すことができます

于 2008-11-19T21:31:19.277 に答える
0

Software Engineering Radio ポッドキャストのエピソード 2 を聞くことをお勧めします。依存性注入に関するエピソード全体です。依存性注入は、制御フレームワークの反転の最も広く知られている使用法です。また、John Kovacs が出演する DotNetRocks エピソード 362 もお勧めします。ここに番組のトランスクリプトがあります。

現在、IOC の副作用として、テスト容易性の向上があります。Castle Windsor のような IOC コンテナーの使用は、依存関係の分離に役立ちます。この分離により、単体テストが改善されます。

ほとんどの IOC フレームワークには、アスペクト指向プログラミングを容易にする方法も付属しています。そのため、その IOC コンテナ フレームワークに興味がある場合は、それを支援できます。

于 2008-11-20T17:50:57.990 に答える