依存性注入、ファイルシステム、コンフィギュレーションオプションと診断ログを含むいくつかのコアフレームワーク、基本的な枠組みに基づいて構築されたASP.NETコアフレームワーク。これらのフレームワークは、ちょうど我々はまた、頻繁にそれらに使用されるアプリケーションの開発時間を作り、基本的なASP.NETコアフレームワークをサポートしていません。ここで言及したこれらのいくつかの基本的な枠組みについては、依存性の注入は特に重要です。ASP.NETコアアプリケーションの起動や処理のための後続の要求は、それがサービスコンポーネントのさまざまに依存します。カスタマイズを容易にするために、これらの成分は、一般にインタフェースの形で「正規化」になり、我々は総称して「サービス（サービス）」と呼ばれるこれらのコンポーネントを標準化します。所望のサービスオブジェクトを提供するために、依存性注入コンテナを使用依存性注入の基礎をなすフレームに基づいてASP.NETコアフレーム全体。この依存性注入コンテナとそのサービス提供の仕組みを理解するために、我々は最初に知らなければならないものを「依存性注入（DI：依存性注入）」。私たちは、依存性注入を述べた後、彼らは、「コントロール（：コントロールの逆IOC）の反転」について話しました。
フロー反転制御
そのような前に人気のSOAとなりましたので、ホット「マイクロ・サービス（マイクロサービス）」と「いいえ、サーバ（サーバレス）」などの明確な定義なしに、多くの場合、いくつかの、いわゆるデザイン・ソフトウェアの開発、我々は法律を通過しませんでした彼らに正確な定義を与えることが、唯一の「拡張子」の記述からアーキテクチャ設計特性のこれらの種類を持っている必要があります「という意味の」クリア。私たちは多くの人々を引き起こした明確な定義を与えていないので、多くの場合、同じ概念について異なる解釈を持っています。これは参考のために、この章の著者は、読者が暫定的にそれを聞く言葉の一つだけを表すためのIoCもそうです。
私は多くの人がIoCのは、「オブジェクト指向のデザインパターン」の一種であると言われますが、私の個人的意見では聞いたことがあるのIoC自体は、「オブジェクト指向」とは直接の関係を持たない「デザインモード」のようなもの、と見なすことができないだけでなく、。多くの人々がそれらの怠慢のIoCフレーズ自体最も基本的なものの一つに、非常に正確なのIoCを理解できない理由。
中国語に翻訳コントロールのIoCのフルネームの逆は、「ある制御の反転」「または逆さまにコントロール。」制御の反転や、言及する価値制御の反転は、それが本来のA、Bの手の中に、そのコントロールのコントロールの平均転送を反映し、今以上取る必要があります。だから、ソフトウェアの設計のため、IOCはそれが具現化したもの制御の転送いわゆる？この質問に答えるために、我々は実際にコントロールの種類を指し、C（コントロール）ののIoCを理解する必要があります。タスクは、その固有のプロセスを有し、IoCのは"として理解することができる制御に関するので、我々は関係なく、その大きさの、実質的に対応するステップ、いずれかの実施形態に分解することができるされているすべてのタスクのための制御処理。 "
制御の流れのための伝統的なデザインを説明するための具体的な例を挙げてのIoCを使用した後に反転を実現する方法です。例えば、我々はそれがMvcLib指名されるかもしれません、ウェブMVCのためのライブラリーをデザインしたいです。簡単にするために、このライブラリは、唯一の静的クラスが同じ名前を次の含まれています。
パブリック 静的 クラスMvcLib { パブリック 静的タスクListenAsync（URIアドレス）。 公共の 静的なタスク<要求> ReceiveAsync（）; パブリック 静的タスク<コントローラ> CreateControllerAsync（要求リクエスト）。 公共の 静的なタスク<表示> ExecuteControllerAsync（コントローラコントローラ）; 公共の 静的なタスクRenderViewAsync（ビュービュー）。 }
MvcLibは、5つのコア業務で全体のHTTPリクエストの処理を完了し、私たちを助けるために5つの方法の上方に設けられました。具体的には、ListenAsyncの方法は、リスナーを開始し、指定されたアドレスリスニングHTTPリクエストにバインドを介して到着要求ReceiveAsync要求を受信するための受信方法は、リクエストオブジェクトによって表されます。CreateControllerAsync分析方法と、受信した要求に応じて目標コントローラオブジェクトを活性化します。ExecuteControllerAsyncの活性化を行い、コントローラビューオブジェクトがビューを表す返す方法。RenderViewAsyncは、最終的には、現在の要求としてHTMLコンテンツにオブジェクトを表示し、要求元のクライアントに応答を返します。
今、私たちはこのMvcLibに基づいて真のMVCアプリケーションを作成します。また、私たちはMvcLib特定し、ビューコントローラのカスタム仕様に応じて、我々はまた、自己制御し、最終的なプレゼンテーションからプロセス全体が活性化し、コントローラの表示を行って、受信したリクエストを監視し、そして、そのような流れの実装、などの必要があることを見つけますなお、以下に示すコードに反映されています。
クラスプログラム { 静的な 非同期タスクのメイン（） { ながら、（真） { VARのアドレス= 新しいウリ（" http://0.0.0.0:8080/mvcapp " ）; 待つMvcLib.ListenAsync（アドレス）。 ながら（真） { VARの要求=を待つ）（MvcLib.ReceiveAsyncします。 VaRのコントローラ= 待つMvcLib.CreateControllerAsync（要求）。 VaRのビューは= 待ちますMvcLib.ExecuteControllerAsync（コントローラ） 待つMvcLib.RenderViewAsync（図）。 } } } }
この例では、以下に示すようにフロー制御モードを反映する（アプリケーション・コード要求に対処するための完全に非同期方法、さらにより簡単のフローチャートを可能にするために、我々は同期のフローチャートの形に描かれ、読者は、この問題をもつれする必要はありません）。我々は単一のAPIの形で様々な機能を実現提供するライブラリ（MvcLib）を設計し、ライブラリ・コンシューマ・アプリケーション（APP）あなたは、自分のワークフロー全体を手配する必要があります。コードの再利用の観点は、ここで単機能の特定の態様を達成するためにコードを再利用することが制限されている場合、全体のワークフロー・コードが再利用されない振付。
しかし、本当の開発シナリオでは、私たちはクラスライブラリよりも、単一のAPIを提供して必要がありますが、枠の上に直接アプリケーションを構築することができます。前者は唯一の目標タスクスケジューリングに対して、後者はこれらの単一機能のための完全なプロセスを形成しながら、いくつかの機能を実装するための単一のAPIを提供し、使用が多いです：図書館（図書館）とフレームワーク（枠組み）は違いがあることですエンジンは自動的にこのプロセスを駆動します。
私たちのMvcLibは、上記立証するために、アプリケーションが全体のHTTPリクエストを制御するための独自のプロセスの消費者として必要ですが、実際には、これは非常に「である一般化ほぼすべてのMVCアプリケーションのようにに使用されているワークフローのは」、モニターするプロセスは、要求と要求への最終的な応答を受け取ります。我々はMVCフレームワークでは、このプロセスを実装する場合、MVCアプリケーションによって構築されたことのすべてが直接処理フローを要求する使用することができ、（それを自分で行います）不要なDIYを行う必要はありません。
今、私たちは暫定的にMvcFrameと呼ばれる、フレームワークにライブラリからMvcLibを変換します。以下に示す、MvcFrameコアは振り付けワークフロー一貫した処理HTTPリクエストを駆動MvcEngine実行エンジンと呼ばれます。我々はMvcFrameは、対応するコントローラとビューよりも私たちのビジネス要件の定義に従う場合を除き、MVCの特定のアプリケーションを構築使用している場合は、我々は唯一のエンジンを初期化する必要があり、それが直接起動することができます。あなたはASP.NET MVCアプリケーション上で働いてきた場合は、ASP.NET MVCは、このようなフレームワークであることがわかります。
伏線の一例として、この前の発表では、我々はIoCのは、コントロールのいわゆる反転に言って理解することは非常に簡単である必要があり、それが何であるか、本質的です。全体的に、IOCは我々がコントロールのいわゆる反転を採用した設計フレームワークの基本的な考え方はあるプロセス制御のアプリケーションがフレームに転送されます。伝統的なライブラリ指向プログラミング、しっかりとアプリケーションの手の中にHTTPリクエスト処理フロー制御の時代に、前の例を見てみましょう。フレーム、フレームの手への転送要求処理制御の導入後。
第二に、ハリウッドのルール
ハリウッドでは、俳優たちは、同社が家に帰って待つ舞台芸術に提出した後にのみ再開します。芸能会社は全体のエンターテインメントを完全に制御を持っているので、映画俳優は受動的に、同社の申し出を受け入れることができます。これは有名なハリウッド（ハリウッド原理やハリウッド低）の法則である「私たちを呼んではいけない、私たちは（私たちはあなたを呼んでよ、私たちを呼んではいけない）あなたを呼ぶことにします」、IOCは完全にこの原則を体現しています。
それは全体のワークフローの事実上のコントロールなので、それだけでリンクしているスタッフが知っておく必要があるためのIoCのコンテキストでは、フレームは、映画会社のマスター映画監督、全体のプロセスのようなものです。俳優のようなアプリケーションでは、それが唯一のフレームワークが自動的に適切なタイミングで登録されたコンポーネントをロードして実行されますので、フレームワークをカスタマイズすることができるルールに従って、これらのコンポーネントを登録する必要があります。
以熟悉的ASP.NET MVC应用开发来说，我们只需要按照约定的规则（比如约定的目录结构和文件与类型命名方式等）定义相应的Controller类型和View文件就可以了。当ASP.NET MVC框架在处理请求的过程中，它会根据路由解析生成参数得到目标Controller的类型，然后自动创建Controller对象并执行它。如果目标Action方法需要呈现一个View，框架会根据预定义的目录约定找到对应的View文件（.cshtml文件），并对它实施动态编译生成对应的类型。当目标View对象创建出来之后，它执行之后生成的HTML会作为响应回复给客户端。可以看出，整个请求流程处处体现了“框架Call应用”的好莱坞法则。
总的来说，我们在一个框架的基础上进行应用开发，就相当于在一条调试好的流水线上生产某种商品。我们只需要在相应的环节准备对应的原材料，最终下线的就是我们希望得到的产品。IoC几乎是所有框架均具有的一个固有属性，从这个意义上讲，“IoC框架”的说法其实是错误的，世界上并没有什么IoC框架，或者说所有的框架都是IoC框架。
三、流程定制
我们采用IoC实现了流程控制从应用程序向框架的转移，但是被转移的仅仅是一个泛化的流程，任何一个具体的应用都可能需要对该流程的某些环节进行定制。还是以我们的MVC框架来说，默认实现的请求处理流程可以只考虑针对HTTP 1.1的支持，但是我们在设计框架的时候应该提供相应的扩展点来支持HTTP 2。作为一个Web框架，用户认证功能是必备的，但是框架自身不能限制于某一种或者几种固定的认证方式，它应该允许我们通过扩展实现任意的认证模式。
私たちは、より広範なポイントを言うことができます。以下に示すように、我々はフレームで定義された一般的なワークフロー（A => B => C）を有する、二つのアプリケーションに基づいて、フレームは、カスタマイズのこのプロセスの組成物の特定の局面を必要とします。例えば、ステップAとCは、App1の再使用することができるが、それは、ステップB（B1）をカスタマイズする必要があります。APP2は、ステップA及びBが、独自の方法Cに必要な処理ステップを再利用します
IOCはプロセス全体の実装のための1つのエンジン駆動の自動化フレームワークと、フレーム内にアプリケーションから転送するプロセスを制御します。アプリケーションは、ワークフローの詳細を気にする必要はありません、それだけでエンジンを始動する必要があります。エンジンが始動されると、フレームが完全になるアプリケーションは、あなたが望む方法で実行されるプロセス全体を望んでいる場合には、優れたプロセスに従って動作するように事前にプログラムされ、あなたがプロセスを開始する前にカスタマイズする必要があります。一般的に言えば、フレームワークは、スケーラブルな方法を達成するために登録することによって、アプリケーション・プロセスの特定の部分にカスタマイズされた適切な形に拡張ポイントの範囲を、提供します。エンジンを始動する前に、アプリケーションがフレームに登録された拡張するために必要となります。エンジンが正常に起動したら、これらの拡張機能は自動的に全体のプロセスの実行に参加するために登録されます。
要約すると、一方のIoC アプリケーションプロセス自体からのフロー制御によるフレームの逆転のための再利用を実現する一方で、このプロセスは、組み込みの拡張メカニズムによって再利用されるようにするためには、自由にカスタマイズすることができ、両方の因子は、それらの値の枠組みを決定します。再利用の枠組みを聞かせていないだけで、単一のAPI機能をアプリケーションとして実装されていますが、我々は、フレームをカスタマイズできるように、間違いなくフレームに使用することができ、さまざまなアプリケーションのためにカスタマイズすることができ、実行ファイルのセットにソリューションを提供するために提供複数のアプリケーション間で。
[ASP.NETコア3フレーム開示]依存性注入：制御の反転
[ASP.NETコア3フレーム開示]依存性注入：IoCのモード
[ASP.NETコア3フレーム開示]依存性注入：依存性注入モード
[ASP.NETコア3フレームワークシークレット]の依存性注入：DIフレームワークのミニバージョン