design-patterns - 依存性注入フレームワークを使用することへの恐怖

Question

私は依存性注入フレームワークについて読んでいます。私は、懸念事項を分離し、オブジェクトにコアワークを任せるというアイデアに本当に恋をしました。これは、間違いなく優れた長年の設計原則です!

しかし、DI フレームワークについて読めば読むほど、次のことが心配になります。

ポイント 2 だけですが、顧客が何百万ドルも費やして製品のトレーニングを行っているのを見てきましたが、その重要な部分は構成ファイルに触れないようにする方法でした。管理者は現在、これらの構成ファイルを恐れています。

それにもかかわらず、アプリケーションの開始時に必要なすべての「グローバル」サービス (アプリケーションホストまたはアプリケーションコンテキストなど) を適切に組み立てることができる Service Locators と呼ばれる別のパターンを目にします。このサービスロケータをグローバルに利用できるようにすると、出来上がりです!

ただし、(誰に知られている?) いくつかの基準に基づいて複数のタイプの「グローバル」サービスが必要な場合に、Service Locator アプローチを使用すると柔軟性が低下することがわかります。

ですから、ここで、どちらの方向に進むべきかについて、以前よりも混乱しています。設計原理はとても気に入っていますが、既存のフレームワークの複雑さにうんざりしています!

私の懸念は本物ですか？他の誰かが同じように感じますか？もしそうなら、そのような非常に圧倒的な「フレームワーク」に代わるものはありますか?

score 3 · Accepted Answer

私は個人的にAutofacの使用をとても楽しんでいます。コンテナーの構成はコードを介して行われると同時に、冗長な XML を排除し、リファクタリングのサポートを有効にします。

ただし、最高の機能の 1 つはモジュールです。これらはコンテナー構成の単位であり、アプリケーションを構成するさまざまなコンポーネントの複雑さを管理できます。

私は現在、非常に大規模なプロジェクトに取り組んでいますが、経験は小規模のときとほぼ同じです。つまり、このアプローチは非常にうまくスケーリングされます。

DI 対応クラスの主な原則は、インフラストラクチャコードを参照しないことです。これは Service Locator パターンとは対照的です。Service Locator の主な欠点は、コンテナーを参照するクラスが複雑になることに加えて、依存関係のどのバージョンを解決するかを変更する機能がないことです。

コンテナーを参照しない「純粋な」クラスでは、特定の依存関係の解決されたバージョンは、注入されるクラスの外部にあります。

score 2 · Accepted Answer

ネイトが述べたように、「魔法」はオプションです。必要に応じて、すべてを手動で構成できます。

最初は (または永遠に) 構成ファイルを使用せず、コードでコンテナーを構成します。その方が、読みやすく維持しやすい傾向にあります。ほとんどの場合、オンザフライで構成を変更する必要はありません。構成ファイルが存在しないため、顧客はそれらに触れることができません。

サービスロケーターには欠点があります。1 つには、クラスをロケータークラス/フレームワークに結合する傾向があります。優れた DI フレームワークでは、プレーンオールドオブジェクトを使用できます。プロジェクトには、実際に DI/IoC フレームワークを使用するクラスが 1 つしかない場合があります。

StructureMap と Unity はどちらも非常にシンプルです。それらを試してみてください。小さく始めましょう。

Unity を使用した非常に単純な例 (インライン構成を含む) を次に示します。

using Microsoft.Practices.Unity;

static void Main()
{
    using (IUnityContainer container = new UnityContainer())
    {
        container.RegisterType<IRobot, MrRoboto>();

        Console.WriteLine("Asking Unity container to give us a Model...");

        Model model = container.Resolve<Model>();
        model.MoveRobot();
    }
}

// class Model

public Model(IRobot robot)
{
    // Unity will hand the constructor an instance of MrRoboto!
}

score 2 · Accepted Answer

依存性注入の方法を真剣に検討している場合は、Martin Fowler の優れた依存性注入に関する記事を一読することを強くお勧めします。

http://martinfowler.com/articles/injection.html

私は現在、多くの構成ファイルを使用して Java プロジェクトに取り組んでいます。構成を表すシングルトンパターンを事前に選択しました (グローバルソリューションに多少似ています)。私を狂気に駆り立て、代わりに依存性注入パターンがあればいいのにと思うものは次のとおりです。

グローバル化されたパターンを使用した単体テストは最悪です。依存性注入パターンは、単体テスト、特にモックオブジェクトテストを容易にするのに役立ちます。シングルトンタイプの場合、これらの単体テストはすべて、実行するためにグローバルな状態を利用できる必要があります。依存性注入を使用すると、テストに渡すテスト固有のモック構成オブジェクトを作成できます。これにより単体テストがどれほど簡単になるかは、いくら強調してもしすぎることはありません。「Endo-Testing: Unit Testing with Mock Objects」というタイトルの別の優れた論文: http://connextra.com/aboutUs/mockobjects.pdf
グローバル化されたアプローチを使用すると、小規模なシステムでうまく機能しますが、スレッドの数が増えると、すべてのスレッドが構成リソースを求めて競合し始めます。同期の問題が発生する可能性があり、構成へのアクセスがボトルネックになり始めることさえあります。これはまだ私たちにとって大きな問題ではありませんが、私たち全員を悩ませ始めています。
非依存性注入ルートを少し下ると、実際に戻ることはありません。依存性注入からある種のグローバル化されたパターンに移行するのは面倒ですが、段階的に実行できます。グローバル化されたパターンから依存性注入に戻ろうとするのは悪夢です。私は私たちのプロジェクトでそれをやりたいと思っていますが、できません。開発サイクル全体が必要になります。

とにかく、この記事と経験があなたの決断に役立つことを願っています. 私はあなたが考えている道のりをずっと進んでいます.

score 1 · Accepted Answer

これらはどちらもDIに「必須」ではなく、一部のDIフレームワークによって提供されるオプションです。個人的には、「automagic」インジェクションも嫌いです。非常に小さなプロジェクトでは機能しますが、大きなプロジェクトでは問題が発生します。ポイント2については、ポイントがわからないので、主にSpringを使用しました。Springは、XMLとJavaの両方の構成オプションを提供します。ネストされた構成を提供します。構成の一部に変更を加えたくない部分があり、変更する部分がある場合は、それらを別々の構成ファイルに分割するか、一方のXMLともう一方のJavaを「変更可能」にします。Springは、プロパティファイルの値の使用もサポートしています。これは、管理者が変更することを期待しているすべての値です。管理者はプログラマーではありません。

score 0 · Accepted Answer

使用する言語によっては、それほど怖くないDIフレームワークがいくつかありますが、いくつかの構成ファイルはありますが、怖くないはずですが、便利です。

たとえば、開発用、テスト用、本番用の1つの構成ファイルがあります。

そのため、使用するものに応じて、データベース接続を変更したり、データベースレイヤーをテスト用に交換したり、模擬テストを使用したりできます。

理想的には、開発者は本番環境に何もプッシュしてはならないため、システム管理者は本番環境の構成ファイルを制御する必要があります。

Springは軽量ではありませんが、DIのセットアップは優れています。

Unity Frameworkを学ぶのは簡単ではないことがわかりましたが、一度使用すると、インジェクション用の新しいクラスを追加するのは非常に簡単です。

したがって、最初は新しいものは怖いかもしれませんが、概念に慣れてくると、3つの構成ファイルについて説明したような利点がわかります。

score 0 · Accepted Answer

私の状況は、非常に柔軟な構成用に設計されたシステムをすでに持っているという点であなたの状況とは異なる可能性があります。そのため、その構成に依存性注入を追加することはほとんど簡単でしたが、サービスロケーターパターンを使用しても、必要な構成をあまり節約できないようです。それでも、サービスの検索方法を指定します。テスト用にモックオブジェクトを柔軟に注入できることは、依存性注入を使用することのほとんど貴重な利点です。したがって、構成のオーバーヘッドは、利点を得るために受け入れる必要のあるビジネスを行うためのコストである可能性があります。

design-patterns - 依存性注入フレームワークを使用することへの恐怖

6 に答える 6

Related

Reference