エンドポイントエンドポイントルーティング3.xのasp.netコア1 - 基本的な導入と使用

序文

私は、私はもともと4.5のowinから形成されたこのようなもののasp.netを感じ、.NET 4.5の.NETコア3.xのから直接ジャンプします。
現在、公式文書はそうでない伝統的なルートとの違いを指摘しない限り、話すルーティングに焦点を当て、この部分は概念がルーティングし、どのように使用するエンドポイントを説明し、詳細なルートを行くことはありません、このOKの公式ドキュメントを参照してください。将来的には、あなたは下の深さ分析に続い勉強してする機会を持っている場合。

参考：
https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/routing?view=aspnetcore-3.1
https://q.cnblogs.com/q/113644/  
https://aregcode.com /ブログ/ 2019 / dotnetcore-理解 -aspnet-エンドポイントルーティング/

アウトライン

我々はhttp://www.abc.com/a.aspxを訪問したときに最初に、サーバーは、私たちは要求を処理するのに対応するクラスのインスタンスを作成するためのファイルサーバによると、このファイルa.aspx存在します。
その後、需要より多くの複雑な、目的が直接プロセッサの要求の実行に関連した要求に対処するためである、そこにルーティングされたが、それは自分自身で設定されたルールをマッピング、マッピングに関連付けられます。
ルーティングシステムasp.netコア3.xのは、MVC内に収容される前に、.NET Frameworkの時代では、システムも含まれているルーティング、MVCを達成するための特別なHttpModuleをを有しています。.NETコアはMVCを達成するための特別なミドルウェアを有するように構成されている、ルーティングシステムは、このミドルウェアに含まれています。
このように、我々はMVCミドルウェア後に他のミドルウェアを追加したい場合は、システムをルーティングすることは、含ま問題、ちょうどミドルウェアMVCあり、他のミドルウェアはできない（おそらく、不便な）アクセスの経路に関連する情報があります。
加算asp.netコア将来的にMVC、そこWEBAPI、blazor、signlR、アクセスgRpcなど、さらに多くないだけで、私たちの提案ルーティングシステムは、すべてのフレームを使用することができますすることができますか？

そのため、エンドポイントのルーティングがあった、私たちはルーティングの基本的な目的は、アドレスのユーザーの要求にであると言う、最も単純な要求プロセッサにマッピングされた要求ハンドラは<HttpCotnext、タスク>は、あってもよいMVC / WEBAPIでデリゲートのFuncかもしれコントローラのアクションは、そう抽象エンドポイントの観点からの要求を処理手数料です。私たちのエンドポイントにもこの要求を委託される処理に関連するデータを格納するコレクションを提供しなければならないので、多くのMVCが、action属性でありますので。
抽象角度は、単にデータに関連付けられた終端点+ =デリゲート追加の処理要求（要素）として理解することができます。対応は、属性セットのMVC =アクション+エンドポイントのアプリケーションを理解します。しかし、エンドポイントは抽象的な概念であり、MVCを提供するだけでなく、おそらく原則を、次の点に注意してください。

1. 私たちはそこに良いプログラムをエンドポイントかを定義する必要があり、プログラムを開始する前に、確かに1我々は、手動で定義されていませんが、自動的にターゲットフレームワークに基づいて生成されたアクション・プログラムが自動的に対応するにルートを一致させることができるため、MVCはケースですエンドポイントは、他のフレームワークも、最終的にすべての要求を処理するために、私たちのもののエンドポイントになっている、とにかく、対応している必要があります。このステップは、ルートの定義に自動的に行われます
2. エンドポイントの定義に加えて、我々は、適切な試合のエンドポイントの要求を見つけるために、将来的にはエンドポイントと要求パスとの対応を定義する必要が私たちの要求に対処するために到着し、このステップでは、ルートを定義するのと同じです
3. また、要求は、Microsoftが対応するミドルウェアパーサーを表すように定義されていることをエンドポイントとパスの間の対応に応じてエンドポイントを見つけるに到着したとき、パーサを定義する必要があります。
4. 最後に、我々はミドルウェアミドルウェアは、我々は現在のリクエストエンドポイントが一致し、最後のコールデリゲートプロセス要求を得ることができる上に、ミドルウェアは、ミドルウェアMVCで行う定義する必要があります
5. このasp.netミドルウェアルーティングコアは、ほぼので、デフォルト3.X、その後、我々は独自のミドルウェアを定義することができ、ステップ3バックで、いくつかの高度なエンドポイント処理を行うようになりました。ミドルウェアのMicrosoftの定義の中には、このルーチンです

使い方

asp.net時にコア3.xのプロジェクト対によって作成されたデフォルトのテンプレートでは、スタートアップコードでこれを見ることができます

1  app.UseRouting（）。
2 app.UseEndpoints（エンドポイント=> {
 3  　　endpoints.MapControllerRoute（
 4  　　　　名：" デフォルト" 、
 5  　　　　パターン：" ？{コントローラ=ホーム} / {アクション=ランキング} / {ID} " ）;
 6 }）。

登録ルート

コードの2行目を参照してください。これは、次の3つのタスクを持っています

1. それは自動的に終了点までの経路上のアクションの形式に一致するようにプログラムを変換しますMVCのためのエンドポイント定義を作成します。Endpoints.DataSourceプロパティは、内側に優れたエンドポイントを生成し、5行目の後に観察デバッグすることができます
2. エンドポイントとURLの対応関係を確立する、存在しているこの関係？私は知りません
3. 登録MVCミドルウェア（その要求が将来的に到着し、現在の要求との試合の終了点の後にミドルウェア前に解決されている、旅はMVCを開始しました）

ここでは、以前の文言とのルートが上記のデフォルト値ああに似ている、ああ制約は、公式文書、それを見に行きました。
ルーティングエンドポイント参照のプロパティを作成し、Microsoftが伝統的なルートを使用して、プロパティWEBAPIルーティング、MVCの使用を推奨しています。あなたは、このようなデフォルトWEBAPIプロジェクトの作成を参照します  ）（endpoints.MapControllersを。 

エンドポイントさらにカスタマイズ

デフォルトは、この世代のエンドポイントは、我々はプロセスに参加できるということです、マッチングのアクション最後の世代のエンドポイントを見つけるために、ルートの定義に基づいて、具体的な対策がendpoints.MapControllerRouteリターンオブジェクトに呼び出すことによって拡張する方法に関連している、本質的には、することですあなたは、プロセスのエンドポイントは、将来のエンドポイントで作成されたいくつかの手数料を、追加作成するときに、次のように、委員会は、呼び出されます。

1  endpoints.MapControllerRoute（
 2                      名：" デフォルト" 、
 3。                      パターン：" {？} {コントローラ} =ホーム/インデックス= {アクション} / ID "）.Add endpointBuilder =>（{
 4。                         // endpointBuilderを得るに関連付けられたアクションを介してそのような属性や他のメタデータなどのデータ、
 5                          // endpointBuilderによってエンドポイントに我々のデータに挿入
6。                      }）;

ダイナミックルーティング

それは、使用MVCとWEBAPIを示しており、デフォルトのアクションは、エンドポイントマッチング要求に対応するエンドポイントが直接実行app.UseEndpointsmvc時間を到着作成します。：しかし、時には我々は、コントローラが使用されている要求オーバーなアクションを、特定のアプローチコントロールしたい
継承DynamicRouteValueTransformerというクラスを定義し、IOCコンテナに登録され、最終的に拡張メソッドを呼び出して、コードを見て：

1      クラスMyRouteValueTransformer：DynamicRouteValueTransformer
 2      {
 3          公共 オーバーライド ValueTask <RouteValueDictionary> TransformAsync（のHttpContextのHttpContext、RouteValueDictionary値）
 4。         {
 5。             // 元ルートデータ値を取得することができる
 6。             // 新しいデータを交換または追加することができる
7。              values.Add（" コントローラ"、" JJ " ）
 。8              values.Add（" アクション"、" KKK " ）
 。9              リターン 新しい ValueTask <RouteValueDictionary> （値）;
10          }
 11      }
 12  
13  公共 ボイドConfigureServices（IServiceCollectionサービス）
 14          {
 15              services.AddSingleton <MyRouteValueTransformer> （）;
16              services.AddControllers（）。
17          }
 18  
19 endpoints.MapDynamicControllerRoute <MyRouteValueTransformer>（" AAA / BBB / {ID} "）。

だから、将来の要求は私達のMyRouteValueTransformer時に通話がエンドポイントを取得することを決議に着いたとき、私たちは道はカスタマイズを実現するように、データを解析され、その後、いくつかのルーティングデータを追加/置き換えることを選択した得ることができます

 

隠れ家から戻ります

一致が直接エンドポイント、404見つからない場合、要求は、到着し、我々は任意のエンドポイントに一致しないとき、直接、デフォルトのエンドポイントを実行することをご希望の場合は、次のようにデフォルトでは、使用することができます。

endpoints.MapFallbackToController（" {コントローラ} / {アクション} / {ID}？"、" KKK "、" JJ "）。

要求が到着すると任意のエンドポイントに一致するものがない場合は、この方法は、jjController.kkkデフォルトを行っています。この機能は、おそらく動的ルーティングを介して達成することができます

でやっているお察しの通り、いくつかの関連する拡張メソッドは、上記の説明であります。あまりにも多くのルートが仮登録について

 

カスタムミドルウェアは先のエンドポイントデータの取得します

）（app.UseRouting;対応3で説明する手順は、この拡張メソッド内ミドルウェアを登録し、要求は、現在の要求が一致してエンドポイントを見つけるために、将来的に私たちを助ける到着とのHttpContextに格納され、一致を解析する工程Request.RouteValuesで得られたルートデータ。私たちは、その背後に、独自のミドルウェアを追加することができます

1  app.UseRouting（）;
 2 app.Use（（conttext、NEXT）=> {
 3。       VARエンドポイントconttext.GetEndpoint =（）; // 取得したエンドポイント
。4        VAR RouteData = conttext.Request.RouteValues; // GETルーティングデータ
　　　　 //何かを牛B 
。5        リターン次に（）;
 6 }）。