シンプルな依存性注入の実現（ゼロ）：ホイールをハンズ作成

イントロ

Microsoftの.NETコアは、マイクロソフトによって開発された依存性注入フレームワークの外に放出しながら、私たちはプログラムを書くための依存性の注入は、多くの利益をもたらしたMicrosoft.Extensions.DependencyInjection、asp.netの伝統的な開発モデルの大きな変化、asp.netコア、より柔軟な、より近代的な、より美しいの開発。

依存性注入の紹介

制御の反転について話をする（IOC）のすべての最初の依存性注入を導入するために、

コントロールのIOC-反転、それは、「制御の反転」、技術的ではないが、デザインのアイデアです。IOCはあなたではなくあなたの内部のオブジェクトの上に伝統的な直接制御するよりも、コンテナコントロールにオブジェクトを設計していることを意味します。

誰が誰とどのような制御を制御：従来のプログラミングを、私たちは直接オブジェクト内に新しいを通じてオブジェクトを作成し、依存オブジェクトを作成するためのプログラム・イニシアチブ;およびIoCのは、これらのオブジェクトを作成するための特別なコンテナである、それはIoCコンテナによって対象を制御するために、あります作成、制御？もちろん、IoCコンテナコントロールオブジェクト。何コントロール？それは（だけでなく、など、このようなファイルなどのオブジェクトを含む）のリソースへの主制御外部からのアクセスです。
逆転されたのはなぜ、逆にどのような：、つまり、フォワード制御に直接依存オブジェクトを取得するオブジェクトに、前方に私たち自身のイニシアチブにより、レガシーアプリケーションを逆にそこに持っている。それはコンテナによって逆転されます作成するのに役立つと依存オブジェクトを注入し、なぜ逆転されますか？コンテナは、依存オブジェクトを検索し、注入たちを支援するので、受動的に依存オブジェクトを、それを受け入れるの目的は、それが逆であり、何が逆？買収は逆に対象物に依存しています。

IoCのプログラミングは、最大の変化は、コードからのものではないもたらすが、変更のイデオロギー、「マスター・スレーブ転置」。アプリケーションは、リソースがイニシアチブを取るためにあるものを手に入れるために、もともと上司だったが、のIoC / DIでアプリケーションが受動的になり、考え、そしてそれが必要なリソースを作成し、注入するパッシブ待っIoCコンテナ。

設計ルールを指向オブジェクトのいずれかのIoCのは良い兆候 - ハリウッドルール：「私たちに来ないでください、私たちはあなたを探している」、つまり、IoCコンテナオブジェクトと依存性注入によって適切なオブジェクトを見つけるのではなく、オブジェクトを検索するためのイニシアチブを取ります。

DI-依存性注入、すなわち、「依存性注入」：コンポーネント間の依存関係、実行時には、容器によって決定されるが、画像は、前記ダイナミック依存性成分にコンテナによって注入されます。依存性の注入は、ソフトウェアシステムに多くの機能を持ってますが、コンポーネントの再利用頻度を向上させるために、そして柔軟でスケーラブルなプラットフォームを構築するためのシステムのためのものではありません。依存性注入機構を介して、我々は達成するために、誰から来た任意のコードなしに特定のリソースを心配することなく、自社のビジネスロジックを完了するために必要なターゲット・リソースを指定することができ、唯一の簡単な設定を必要としています。

「依存性、依存している理由は、何か注入し、注入された」私たちは徹底的に分析することがあります：DIは、理解するための鍵です。

　　もちろん、次のとおりです。●誰が誰に依存IoCコンテナに依存したアプリケーションは、

　　●なぜに依存している：アプリケーションが外部リソースに必要なオブジェクトを提供するために、IoCコンテナを必要とします。

　　●誰が注入：明らかに依存オブジェクトでIoCコンテナ注入用途 ;

　　されている：●何を注射したオブジェクト/依存性のために必要な外部リソースに注入。

依存性注入は、明示的に「オブジェクトの依存関係がIoCコンテナの構成に依存するオブジェクトを注入している」述べたコントロールの依存性注入の反転は、デザインのアイデアの実装です。

利点は、注射によって異なります。

オブジェクトが作成され、IOCのコンテナに完全に破壊されたアプリケーションを作成する必要はありませんし、興味の対象を、破壊されたC＃の場合はどこIDisposableに重要なオブジェクトには、自身が新しいの際に、いくつかの初心者のためかもしれません使用することを忘れusingたり、手動でdispose
時間の経過と共に作成するたびに行く必要がないオブジェクトの再利用、そして時には多くのオブジェクトは、オブジェクトの同じライフサイクルでのIOCを使用して制御することができ、一度だけ作成されます
明確な依存関係
より良い指向プログラミング・インタフェースを実現する、代替の実装は、それが実現したときに、別のサービスに注入する必要があります

おそらくデザイン

一般的に、Microsoftの使用依存性注入フレームワークに似てますが、Microsoftの依存性注入よりも最適化されるためのフレームワーク単純、パフォーマンス。

サービスライフサイクル：ライフサイクルサービスを分け、MicrosoftのサービスのライフサイクルをたどるSingleton/ Scoped/ Transientデフォルトは、Singletonシングルトン
サービス登録：マイクロソフトは、依存性注入を登録されているすべての方法をサポートし、注入/注入タイプ/インタフェースの例 - 注入/ FUNC注入を達成
注入方法：現在、未来はプロパティインジェクションをサポートするためのプランがないこと、依存性注入のコンストラクタインジェクションをサポートしています（それをサポートして複雑ではなく、依存性は明確ではなく、また推奨）、コンストラクタインジェクションサポート直接注入IEnumerable<T>かIReadOnlyCollection<T>またはIReadOnlyList<T>、複数のインターフェイスを注入するための一般的な注入のためのサポートをアクセスをサポートするために

図DIクラス：

経験

試験基準セルであってもよいです。

using(IServiceConatiner container = new ServiceContainer())
{
    container.AddSingleton<IConfiguration>(new ConfigurationBuilder()
         .AddJsonFile("appsettings.json")
         .Build()
    );
    container.AddScoped<IFly, MonkeyKing>();
    container.AddScoped<IFly, Superman>();

    container.AddScoped<HasDependencyTest>();
    container.AddScoped<HasDependencyTest1>();
    container.AddScoped<HasDependencyTest2>();
    container.AddScoped<HasDependencyTest3>();
    container.AddScoped(typeof(HasDependencyTest4<>));

    container.AddTransient<WuKong>();
    container.AddScoped<WuJing>(serviceProvider => new WuJing());
    container.AddSingleton(typeof(GenericServiceTest<>));

    var rootConfig = container.ResolveService<IConfiguration>();

    Assert.Throws<InvalidOperationException>(() => container.ResolveService<IFly>());
    Assert.Throws<InvalidOperationException>(() => container.ResolveRequiredService<IDependencyResolver>());

    using (var scope = container.CreateScope())
    {
        var config = scope.ResolveService<IConfiguration>();

        Assert.Equal(rootConfig, config);

        var fly1 = scope.ResolveRequiredService<IFly>();
        var fly2 = scope.ResolveRequiredService<IFly>();
        Assert.Equal(fly1, fly2);

        var wukong1 = scope.ResolveRequiredService<WuKong>();
        var wukong2 = scope.ResolveRequiredService<WuKong>();

        Assert.NotEqual(wukong1, wukong2);

        var wuJing1 = scope.ResolveRequiredService<WuJing>();
        var wuJing2 = scope.ResolveRequiredService<WuJing>();

        Assert.Equal(wuJing1, wuJing2);

        var s0 = scope.ResolveRequiredService<HasDependencyTest>();
        s0.Test();
        Assert.Equal(s0._fly, fly1);

        var s1 = scope.ResolveRequiredService<HasDependencyTest1>();
        s1.Test();

        var s2 = scope.ResolveRequiredService<HasDependencyTest2>();
        s2.Test();

        var s3 = scope.ResolveRequiredService<HasDependencyTest3>();
        s3.Test();

        var s4 = scope.ResolveRequiredService<HasDependencyTest4<string>>();
        s4.Test();

        using (var innerScope = scope.CreateScope())
        {
            var config2 = innerScope.ResolveRequiredService<IConfiguration>();
            Assert.True(rootConfig == config2);

            var fly3 = innerScope.ResolveRequiredService<IFly>();
            fly3.Fly();

            Assert.NotEqual(fly1, fly3);
        }

        var flySvcs = scope.ResolveServices<IFly>();
        foreach (var f in flySvcs)
            f.Fly();
    }

    var genericService1 = container.ResolveRequiredService<GenericServiceTest<int>>();
    genericService1.Test();

    var genericService2 = container.ResolveRequiredService<GenericServiceTest<string>>();
    genericService2.Test();
}

詳細についてを参照してください：< https://github.com/WeihanLi/WeihanLi.Common/blob/dev/test/WeihanLi.Common.Test/DependencyInjectionTest.cs >

もっと

ソース既にGithubの上、あなたは、このようないくつかの記事シェアの解釈の背面など、自分で表示またはダウンロードすることができます