翻訳者からの紹介

この記事は、ASP.NET 5-ASP.NET 5ランタイムの詳細-DNXアーキテクチャとその上に構築されたASP.NET 5の概要です。元の記事は2015年3月にASPの時代に書かれたものです。 NET 5はまだ活発に開発されており（およそベータ3）、その多くは時代遅れでした。したがって、すべての情報を翻訳してASP.NET 5（RC1）の現在のバージョンに更新すると、関連リソース（主にdocs.asp.net）およびGitHubのソースコードへのリンクも追加されました（実装に興味がある場合のみ参照））素敵なダイビングを！

.NETランタイム環境（DNX）

ASP.NET 5は、さまざまな.NET CLR（.NET Core CLR、Mono CLR、.NET Framework CLR）で動作できる柔軟なクロスプラットフォームランタイムに基づいています。完全な.NET Frameworkを使用してASP.NET 5を実行するか、新しい.NET Core ^docsの使用を開始できます。これにより、必要なすべてのライブラリをアプリケーションと共に既存の環境にコピーできます。 .NET Coreを使用すると、 Linux ^{ドキュメント}およびMac OS ^{ドキュメントで} ASP.NET 5クロスプラットフォームを実行することもできます。

ASP.NET 5アプリケーションを実行および実行できるインフラストラクチャは、 .NETランタイム環境 ^{ドキュメント、}または略してDNXと呼ばれます。 DNXは、ホストプロセス、CLRホスティングロジック、管理対象エントリポイントの検出など、.NETアプリケーションの実行に必要なすべてを提供します。

論理的に、DNXアーキテクチャには5つの層があります。これらの各レイヤーとその責任について説明します。

DNX構造 ^wiki記事からの画像

レイヤー1：ネイティブプロセス

ネイティブプロセス（オペレーティングシステムプロセスを意味します）は、ネイティブCLRホストを見つけて呼び出す義務があり、プロセス自体に渡された引数を渡します。 Windowsでは、これはdnx.exeです（％YOUR_PROFILE％/。Dnx / runtimes /％CHOOSEN_RUNTIME％にあります）。 MacおよびLinuxでは、これは実行可能なbashスクリプト（dnxとも呼ばれます）です。

IIS ^{ドキュメントでの} 起動は、IISにインストールされているネイティブHTTPモジュールであるHTTPPlatformHandler （最終的にはdnx.exeも実行します）を使用して行われます。 HTTPPlatformHandlerを使用すると、.NET Frameworkに依存せずにIIS上でWebアプリケーションを実行できます（当然、完全な.NET Frameworkではなく.NET Coreを対象とするWebアプリケーションを起動する場合）。

注：DNXアプリケーション（ASP.NET 5コンソールとWebアプリケーションの両方）は、このネイティブプロセスのアドレス空間で実行されます。 これからは、「ネイティブプロセス」の下で、dnx.exeと他のオペレーティングシステムの類似物を意味します。

レイヤー2および3：ネイティブCLRホストおよびCLR

彼らには3つの主な責任があります。

CLRを実行します。これを実現する方法は、使用するCLRのバージョンによって異なりますが、結果は1つになります。
CLRで4番目のレイヤーコード（エントリポイント管理）の実行を開始します。
ネイティブCLRホストが制御を返すと、「それ自体をクリーンアップ」し、CLRをオフにします。

レイヤー4：エントリポイント管理

注：一般に、このレイヤーのロジックはMicrosoft.DNX.Host ^githubアセンブリ内にあります。 このレイヤーのエントリポイントは、 RuntimeBootstrapper ^githubと見なすことができます。

これは、DNXアプリケーションの作業がマネージコードの実行に進む最初の層です（そのため）。彼は責任があります：

ILoadersのコンテナーであるLoaderContainer ^github を作成します。 ILoaderは、アセンブリの読み込みを担当します。 CLRがLoaderContainerにアセンブリの提供を要求すると、ILRを使用してこれを行います。
選択したdnxランタイムのbinフォルダーから必要なアセンブリをロードするルート ^github ILoaderの作成：％YOUR_PROFILE％/。Dnx / runtimes /％CHOOSEN_RUNTIME％/ bin /および--lib

パラメーターを使用してネイティブプロセスの開始時に提供される追加のパス： dnx --lib <LIB_PATHS>

）。
^github IApplicationEnvironmentおよびDependency Injectionシステムのコアインフラストラクチャを構成します。
アプリケーションの起動時にネイティブプロセスに渡されるパラメーターに応じて、特定のアプリケーションのエントリポイント ^githubまたはMicrosoft.DNX.ApplicationHost ^github の呼び出し。

レイヤー5：アプリケーションホスト

Microsoft.DNX.ApplicationHost ^githubは、DNXに付属のアプリケーションホストです。彼の責任は次のとおりです。

インストールされたNuGetパッケージやRoslynを使用してランタイムにコンパイルされたソースなど、さまざまなソースからアセンブリをロードできるgitCon追加アセンブリローダー（ILoaders）をLoaderContainerに追加します。
project.jsonで指定された依存関係を表示してダウンロードします。依存関係トラバーサルロジックについては、 Dependency-Resolution ^wikiで詳しく説明されてい^ます。
コンソールアプリケーションの場合はアセンブリのエントリポイント ^githubを ^呼び出し、Webアプリケーションの場合はエントリポイントMicrosoft.AspNet.Hosting ^{githubを呼び出し}ます。アセンブリは、ApplicationHost が ^github を呼び出す方法を知っているエントリポイントを持つものであれば何でも^かまいません。 DNX ApplicationHostを使用すると、 ^github public static void Main

メソッドを見つける方法がわかります。

クロスプラットフォームSDKツール

DNXには、クロスプラットフォームの.NETアプリケーションの構築に必要なすべてを含むSDKが付属しています。

DNVM -DNXバージョンマネージャー ^wiki 。コンピューターにインストールされているDNXを表示し、新しいものをインストールして、使用するものを選択できます。

^{ドキュメントを} インストールしたら、コマンドラインからDNVMを使用できます。dnvmと入力するだけdnvm

。

DNVMは、DNX_FEED環境変数を使用するように構成されたNuGetフィードからDNXを設定します。 DNXは、伝統的な意味でのNuGetパッケージではありません。依存関係として参照できるパッケージです。 NuGetは、DNXを提供およびバージョン管理する便利な方法です。デフォルトでは、DNXは、アーカイブをDNXから「％USERPROFILE％/。Dnx」にコピーおよびアンパックすることにより設定されます。

DNU -DNXユーティリティ ^wiki 。 NuGetパッケージをインストール、復元、作成するツール。デフォルトでは、パッケージは「％USERPROFILE％/。Dnx / packages」にインストールされますが、global.jsonファイルに別のパスを設定することでこれを変更できます（プロジェクトのSolution Itemsフォルダーにあります）。

DNUを使用するには、コマンドプロンプトでdnu

と入力します。

.NETのクロスプラットフォームコンソールアプリケーション

次に、DNXを使用してシンプルなクロスプラットフォームの.NETコンソールアプリケーションを作成する方法を示します。

エントリポイントでDLLを作成する必要があり、Visual Studio 2015の「コンソールアプリケーション（パッケージ）」テンプレートを使用してこれを行うことができます。

アプリケーションのコード：

 namespace ConsoleApp { public class Program { public static void Main(string[] args) { Console.WriteLine("Hello World"); Console.ReadLine(); } } }

コードは、通常のコンソールアプリケーションとまったく同じに見えます。

このアプリケーションは、Visual Studioまたはコマンドラインから起動できます。コマンドラインでdnx run

と入力し、起動するアプリケーションのproject.jsonファイル（プロジェクトルート）が含まれるフォルダーに移動します。

dnx run

は単なる省略形であり、ネイティブプロセスは実際にコマンドに展開します。

 dnx.exe --appbase . Microsoft.DNX.ApplicationHost run

パターンに一致するもの：

 dnx.exe --appbase <   > <,  entry point> <,    >

展開されたコマンドを分析しましょう：

dnx.exe

はネイティブプロセスです。
--appbase .

-起動したプロジェクトのフォルダーへのパスを指定します。値は「 .

」です-現在のディレクトリを示します。
Microsoft.DNX.ApplicationHost

エントリポイントを持つアセンブリ。デフォルトでは、Microsoft.DNX.ApplicationHostが使用されます。4番目のレイヤー（4番目のレイヤー：マネージエントリポイント、 4番目の責任）を引き起こすのは彼のエントリポイントです。 4番目の層には、Microsoft.DNX.ApplicationHostに関する特別な知識はありません。彼は単に提供されたアセンブリのエントリポイントを探して呼び出し、パラメーターを渡します（この例では、「 run

」がパラメーターとして渡されます）。
run

エントリポイントを持つアセンブリに渡されるパラメーター。 Microsoft.DNX.ApplicationHostは、 run

を--appbase

パラメーターで指定されたパスでプロジェクトのエントリポイントを見つけて呼び出すように指示するコマンドとしてrun

を解釈しrun

。 run

コマンドの代わりに、エントリポイントでアセンブリの名前を渡すことができ、ApplicationHostはそれを呼び出します。以下のWebアプリケーションホスティングセクションでは、この例を見ていきます。

ApplicationHostを使用しない場合。アプリケーションに直接渡すことで、ネイティブ層を呼び出すことができます。これを行うには：

アプリケーションのビルドを実行してDLLを生成します（プロジェクトのプロパティの[ビルド]セクションにある[ビルド時に出力を生成する]チェックボックスをオンにします）。ソリューションフォルダーのルートにあるアーティファクトディレクトリで結果を見つけることができます（プロジェクトのproject.jsonファイルを含むフォルダーに入力することで、 dnu build

ではなくdnu build

使用することもできます）。
コマンドdnx <_______>

ます。

DLLを直接呼び出すことは、アプリケーションを作成するためのかなり低レベルのアプローチです。 Microsoft.DNX.ApplicationHostを使用しないため、project.jsonファイルと改良されたNuGetベースの依存関係管理メカニズムの使用を拒否します。代わりに、依存するライブラリは、 --lib

パラメーターを使用してネイティブプロセスを開始するときに指定されたディレクトリからロードされます。この記事の最後まで、Microsoft.DNX.ApplicationHostを使用します。

Microsoft.DNX.ApplicationHost-DNXの最後の層であり、それより上位のすべてはASP.NET 5と見なすことができます。

ASP.NET 5

Webアプリケーションホスティング

ASP.NET 5 Webアプリケーションでは、 ^{ドキュメント} ホスティングレイヤーはMicrosoft.DNX.ApplicationHostの上で実行されます。これは、 Microsoft.AspNet.Hosting ^githubアセンブリによって表されます。この層は、Webサーバーを見つけ、その上でWebアプリケーションを起動し、Webアプリケーションのシャットダウン中に「自身をクリーニング」します。また、 ^github アプリに追加のレイヤー関連のホスティングサービスを提供します。

Webアプリケーションを起動するには、Microsoft.DNX.ApplicationHostがエントリポイント ^github メソッド Microsoft.AspNet.Hostingを呼び出す必要があります。

ホスティングで使用されるWebサーバーは、 --server

オプションを指定するか、hosting.jsonファイルや環境変数などの他のホスティング設定方法を使用して選択できます。ホスティングレイヤーは、選択したWebサーバーをロードして起動します。ダウンロードできるように、よく使用されるWebサーバーは、project.jsonファイルの依存関係リストにリストする必要があります。

通常、コマンドラインからWebアプリケーションを起動するには、 dnx web

コマンドを使用します。

ASP.NET 5 Webアプリケーションテンプレートには、project.jsonファイルで定義された一連の ^docs コマンドが含まれており、 web

コマンドはそれらの1つです。

  "commands": { "web": "Microsoft.AspNet.Server.Kestrel", "ef": "EntityFramework.Commands" },

実際、コマンドはdnx.exe

追加の引数を設定するだけで、 dnx web

と入力してWebアプリケーションを起動すると、実際には次のように変換されます。

 dnx.exe --appbase . Microsoft.DNX.ApplicationHost Microsoft.AspNet.Server.Kestrel

次に、エントリポイントの呼び出しMicrosoft.AspNet.Server.Kestrel ^githubは呼び出しに変換されます。

 Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel

したがって、最終的なコマンドは次のようになります。

 dnx.exe --appbase . Microsoft.DNX.ApplicationHost Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel

その結果、Microsoft.DNX.ApplicationHostはエントリポイントメソッドMicrosoft.AspNet.Hostingを呼び出します（クロスプラットフォームコンソールアプリケーションのセクションで、実行する代わりにアセンブリ名を渡すと、ApplicationHostがエントリポイントを呼び出すと言いました）。

docs.asp.netドキュメントのホスティングに関する記事は準備ができていませんが、ホスティングの構成に使用されるキーについてはこちらをご覧ください。

Webアプリケーションの起動ロジック

ホスティングレイヤーは、 ^{ドキュメント} Webアプリケーションの^github 開始ロジックを起動する役割も果たします。以前はGlobal.asaxファイルにありましたが、現在はデフォルトでStartupクラスにあり、リクエスト処理パイプラインの構築に使用されるConfigureメソッドと、Webアプリケーションサービスの設定に使用されるConfigureServicesメソッドで構成されています。

 namespace WebApplication1 { public class Startup { public void ConfigureService(IServiceCollection services) { //       } public void Configure(IApplicationBuilder app) { //      } } }

Configureメソッドは、 IApplicationBuilder ^githubインターフェイスを使用して、リクエスト処理パイプラインを構築します。 IApplicationBuilderを使用すると、リクエスト処理パイプラインでリクエストデリゲート（「使用」メソッド）を登録し、ミドルウェア（「UseMiddleware」メソッド）を登録できます。

リクエストデリゲートは、ASP.NET 5の重要な概念です。リクエストデリゲートは、着信リクエストハンドラであり、HttpContextを受け入れ、非同期で有用な処理を行います。

 public delegate Task RequestDelegate(HttpContext context);

ASP.NET 5での要求処理は、登録された要求デリゲートのチェーンに沿った呼び出しです。ただし、チェーン内の次のリクエストデリゲートを呼び出す決定は作成者に委ねられるため、各リクエストデリゲートはリクエストの処理を停止して、ユーザーに応答を返すことができます。

次の要求デリゲートを呼び出さない要求デリゲート要求処理パイプラインでの登録を簡素化するには、Run拡張メソッドIApplicationBuilderを使用できます。

 public void Configure(IApplicationBuilder app) { app.Run(async context => await context.Response.WriteAsync("Hello, world!")); }

Use拡張メソッドを使用し、次のリクエストデリゲートを呼び出さなくても同じことが実現できます。

 public void Configure(IApplicationBuilder app) { app.Use(next => async context => await context.Response.WriteAsync("Hello, world!")); }

そして、リクエストデリゲートチェーンで次を呼び出す例：

 public void Configure(IApplicationBuilder app) { app.Use(next => async context => { await context.Response.WriteAsync("Hello, world!"); await next.Invoke(context); }); }

要求デリゲートを簡単に再利用できるようにするために、 ASP.NET 5ミドルウェア ^{ドキュメントの}形式でフォーマットすることができます。

ミドルウェア

ミドルウェアASP.NET 5は、特定の規則に従う通常のクラスです。

チェーン内の次の要求デリゲート（および必要なサービスと追加パラメーター）はミドルウェアコンストラクターに渡されます。
HttpContext処理ロジックは、非同期のInvokeメソッドに実装する必要があります。

ミドルウェアの例：

 using Microsoft.AspNet.Builder; using Microsoft.AspNet.Http; using System.Threading.Tasks; public class XHttpHeaderOverrideMiddleware { private readonly RequestDelegate _next; public XHttpHeaderOverrideMiddleware(RequestDelegate next) { _next = next; } public Task Invoke(HttpContext httpContext) { var headerValue = httpContext.Request.Headers["X-HTTP-Method-Override"]; var queryValue = httpContext.Request.Query["X-HTTP-Method-Override"]; if (!string.IsNullOrEmpty(headerValue)) { httpContext.Request.Method = headerValue; } else if (!string.IsNullOrEmpty(queryValue)) { httpContext.Request.Method = queryValue; } return _next.Invoke(httpContext); } }

要求デリゲートチェーンの次の呼び出し（次を呼び出す場合）は、Invokeメソッド内で行う必要があります。次のリクエストデリゲートの呼び出しの下にロジックを配置すると、リクエストに続くすべての着信リクエストハンドラが完了した後に実行されます。

要求処理パイプラインでは、IApplicationBuilderメソッドのUseMiddleware<T>

拡張機能を使用して、この規則に従ってミドルウェアを含めることができます。

 public void Configure(IApplicationBuilder app) { app.UseMiddleware<XHttpHeaderOverrideMiddleware>(); }

このメソッドに渡されるパラメーターは、 RequestDelegate next

および要求されたサービスの後にミドルウェアコンストラクターで実装されます。

さらにサービスとパラメーターを受け入れるミドルウェアコンストラクター：

 public XHttpHeaderOverrideMiddleware(RequestDelegate next, SomeServise1 service1, SomeServise2 service2, string param1, bool param2) { _next = next; }

リクエスト処理パイプラインにミドルウェアを含め、パラメーターを渡す：

 public void Configure(IApplicationBuilder app) { app.UseMiddleware<XHttpHeaderOverrideMiddleware>(param1, param2); }

慣例により、呼び出しチェーンへのミドルウェアの組み込みは、IApplicationBuilderの「Use ...」拡張メソッドの形式で行う必要があります。

 public static class BuilderExtensions { public static IApplicationBuilder UseXHttpHeaderOverride( this IApplicationBuilder builder) { return builder.UseMiddleware<XHttpHeaderOverrideMiddleware>(); } }

このミドルウェアをリクエスト処理パイプラインに含めるには、Configureメソッドでこの拡張メソッドを呼び出す必要があります。

 public void Configure(IApplicationBuilder app) { app.UseXHttpHeaderOverride(); }

ASP.NET 5には、組み込みミドルウェアの大規模なセットが付属しています。 ^{ドキュメント} ファイル、ルーティング ^{ドキュメント} 、エラー処理、 ^{ドキュメント} 診断、およびセキュリティを操作するためのミドルウェアがあります。ミドルウェアは、nuget.orgを通じてNuGetパッケージとして出荷されます。

サービス

ASP.NET 5は、サービスの概念を導入します。これは、アプリケーション内のいくつかの場所でアクセスが必要となる可能性のある「共通」コンポーネントです。サービスは、依存性注入システムを介してアプリケーションで利用できます。 ASP.NET 5には、コンストラクターでの依存性注入をサポートする単純な^{ドキュメント} IoCコンテナーが付属していますが、その^{ドキュメント}を別のコンテナーに簡単に置き換えることができます。

Startupクラスは依存関係の注入もサポートしています。コンストラクターパラメーターとしてクエリを実行するだけです。

 public Startup(IApplicationEnvironment appEnv) { }

デフォルトでは、次のサービスを利用できます。

Microsoft.Extensions.PlatformAbstractions.IApplicationEnvironment-アプリケーションに関する情報（アプリケーションフォルダーへの物理パス、その名前、バージョン、ランタイムフレームワークで使用される構成（リリース、デバッグ））。

Microsoft.Extensions.PlatformAbstractions.IRuntimeEnvironment -DNXランタイムおよびOS情報。

Microsoft.AspNet.Hosting.IHostingEnvironment-アプリケーションのWebルート（通常は「wwwroot」フォルダー）へのアクセス、および現在の環境に関する情報（dev、stage、prod）。

Microsoft.Extensions.Logging.ILoggerFactoryは、 ^{ドキュメント} ロガーを作成するためのファクトリです。

Microsoft.AspNet.Hosting.Builder.IApplicationBuilderFactory -IApplicationBuilderを作成するためのファクトリー（要求パイプラインのビルドに使用）。

Microsoft.AspNet.Http.IHttpContextFactoryは、Httpコンテキストを作成するためのファクトリーです。

Microsoft.AspNet.Http.IHttpContextAccessor-現在のHttpコンテキストへのアクセスを提供します。

IServiceCollection ^githubインターフェイスを使用して、StartupクラスのConfigureServicesメソッドでアプリケーションにサービスを追加できます。通常、フレームワークとライブラリは、IServiceCollectionの「Add ...」拡張メソッドを提供して、IoCコンテナにサービスを追加します。たとえば、ASP.NET MVC 6で使用されるサービスの追加は次のように行われます。

 public void ConfigureServices(IServiceCollection services) { //   MVC services.AddMvc(); }

IoCコンテナに独自のサービスを追加できます。追加されるサービスは、transient（AddTransientメソッドIServiceCollection）、scoped（AddScopedメソッドIServiceCollection）、singleton（AddSingletonメソッドIServiceCollection）の3つのタイプのいずれかです。

 public void ConfigureServices(IServiceCollection services) { services.AddTransient<CustomService1>(); services.AddScoped<CustomService2>(); services.AddSingleton<CustomService3>(); }

コンテナからのリクエストごとに一時的なサービスが作成されます。スコープサービスは、現在のスコープで作成されていない場合にのみ作成されます。 Webアプリケーションでは、各リクエストに対してスコープコンテナが作成されるため、各HTTPリクエストに対して作成されるサービスと考えることができます。シングルトンサービスは、アプリケーションのライフサイクルごとに1回だけ作成されます。

依存関係の注入にアクセスできないコンソールアプリケーションでは、静的なMicrosoft.Extensions.PlatformAbstractions.PlatformServices.Default

オブジェクトを使用して、サービスにアクセスする必要があります：IApplicationEnvironmentおよびIRuntimeEnvironment。

アプリケーション構成

Web.configおよびapp.configファイルはサポートされなくなりました。代わりに、ASP.NET 5は、新しく簡素化された構成API ^{ドキュメントを} 使用します。さまざまなソースからデータを受信できます。デフォルトの構成プロバイダーは、JSON、XML、INI、コマンドライン引数、環境変数、およびコードからのパラメーターの直接設定（メモリ内コレクション）をサポートしています。複数のソースを指定でき、それらは追加された順序で使用されます（最後に追加されたソースは、以前に追加された設定を上書きします）。また、 ^{ドキュメント} 環境ごとに異なる設定（test、stage、prod）を設定することもできます。これにより、さまざまな環境でのアプリケーションの公開が容易になります。

appsettings.jsonファイルの例：

 { "Name": "Stas", "Surname": "Boyarincev" }

構成APIを使用してアプリケーション構成を取得する例：

 var builder = new ConfigurationBuilder() .AddJsonFile("appsettings.json") .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) .AddEnvironmentVariables(); var Configuration = builder.Build();

GetSectionメソッドとキー名を使用してデータを要求できます。

 var name = Configuration.GetSection("name"); var surname = Configuration.GetSection("surname");

または、インデックスによる連絡：

 var name = Configuration["name"]; var surname = Configuration["surname"];

StartupクラスでConfiguration APIを操作し、設定を任意の機能に対応する小さなデータセットに分割し、 Options ^docsメカニズムを使用してアプリケーションの他の部分に設定することをお勧めします。

オプションメカニズムを使用すると、Plain Old CLR Object（POCO）クラスを設定付きのオブジェクトとして使用できます。 ConfigureServicesメソッドでIServiceCollectionのAddOptions拡張メソッドを呼び出すことにより、アプリケーションに追加できます。

 public void ConfigureServices(IServiceCollection services) { //  Options   services.AddOptions(); }

実際、AddOptionsを呼び出すと、依存関係注入システムにIOptions<TOption>

が追加されます。このサービスを使用して、依存関係の注入が可能な場所であれば、さまざまなタイプのオプションを取得できます（ IOption<TOption>

からの要求だけで、TOption POCOは必要な設定を持つクラスです）。

オプションを登録するには、 Configure<TOption>

拡張メソッドIServiceCollectionを使用できます。

 public void ConfigureServices(IServiceCollection services) { services.Configure<MvcOptions>(options => options.Filters.Add( new MyGlobalFilter())); }

上記の例では、 MvcOptions ^githubは、MVCフレームワークがユーザーから設定を取得するために使用するクラスです。

構成設定の一部をオプションに簡単に渡すこともできます。

 public void ConfigureServices(IServiceCollection services) { //Configuration -       services.Configure<MyOptions>(Configuration); }

この場合、構成の設定キーは、設定クラスのPOCOプロパティ名にマップされます。

また、アプリケーション内で設定された設定でMyOptionsを取得するには、たとえばコントローラーのコンストラクターを介して、依存関係IOption<MyOptions>

システムIOption<MyOptions>

から要求するだけで十分です。

 public HomeController(IOptions<MyOptions> appOptions) { }

内部的に、Optionsメカニズムは、 IConfigureOptions<TOptions>

をサービスコンテナーに追加することで機能します。TOptionsは設定クラスです。 IOptions<TOption>

の標準実装はIConfigureOptions<TOptions>

同じタイプのすべてのIOptions<TOption>

を収集し、「それらのプロパティを要約」して、最終インスタンスを提供します。これは、同じタイプの設定を持つオブジェクトをサービスコンテナに何度も追加できるためです。設定を上書きします。

Webサーバー

Webサーバーが起動するとすぐに、着信要求の待機が開始され、各要求の処理プロセスが開始されます。 Webサーバーのレベルは、要求をホスティングレベルに上げ、一連の機能インターフェイスを送信します。ファイル、Webソケット、セッションサポート、クライアント証明書、および他の多くの ^{ドキュメント}を送信するための機能インターフェイスがあります。

たとえば、Httpリクエストの機能インターフェイス：

 namespace Microsoft.AspNet.Http.Features { public interface IHttpRequestFeature { string Protocol { get; set; } string Scheme { get; set; } string Method { get; set; } string PathBase { get; set; } string Path { get; set; } string QueryString { get; set; } IHeaderDictionary Headers { get; set; } Stream Body { get; set; } } }

Webサーバーは、機能インターフェイスを使用して、低レベルの機能をホスティングレベルに公開します。そして彼は、 HttpContext

を通じてアプリケーション全体でそれらを利用できるようにします。これにより、Webサーバーのレベルとホスティングとの密接な関係を破り、さまざまなWebサーバーにアプリケーションを配置できます。 ASP.NET 5には、HTTP.SYS（ Microsoft.AspNet.Server.WebListener ）上のラッパーと、 Kestrel ^githubという新しいクロスプラットフォームWebサーバーが付属しています。

.NET（OWIN）のオープンWebインターフェイスは、これらの目標を共有する標準です。 OWINは、.NETサーバーとアプリケーションが相互に通信する方法を標準化します。 ASP.NET 5 は、 Microsoft.AspNet.Owin ^githubパッケージを使用してOWIN ^{ドキュメント}をサポートしています。 ^github ASP.NET 5 OWIN-based - OWIN middleware ^github ASP.NET 5 pipeline.

Katana Project Microsoft OWIN ASP.NET ASP.NET 5. Katana pipeline middleware -. , Katana, OWIN , ASP.NET 5 . Katana middleware ASP.NET 5 OWIN ^github

まとめ

ASP.NET 5ランタイムは、クロスプラットフォームWebアプリケーションをサポートするためにゼロから構築されています。ASP.NET 5には、完全な.NET Framework、.NET Core、さらにはMonoで実行できる柔軟な多層アーキテクチャがあります。新しいホスティングモデルにより、ミドルウェアを使用してアプリケーションを簡単に作成し、さまざまなWebサーバーでホストできます。また、依存関係の注入と新しい改良されたアプリケーション構成機能もサポートします。

リンク集

github.com/aspnetはASP.NET 5のソースコードです

。docs.asp.netはASP.NET 5 のドキュメントです

。github.com/ aspnet / Home / wikiはDNXランタイムに関する記事です。

ASP.NET 5ランタイムに飛び込む