ASPについてNET Routingのいくつかの内容

5384 ワード

はい、このタイトルは8株あることを認めます.
前の文章では、ASPについて聞かれた友達がいました.NET Routingの内容.このコンポーネントの重要性はますます大きくなっています.ASP.NET MVC,ASP.NET Dynamic DataはすべてASPを使用する.NET Routing.実際、ASP.NET 4.0には、対ASPも登場する.NET WebFormsのサポート.残念なことに、現在ASP.NET Routingの文書も記述内容も少ない.そのため、時にはいくつかの友达が私の拡張した設計の構想を理解できないかもしれません.今ASPについて詳しく説明するつもりです.NET Routingで最もよく見られるいくつかの問題.

ASP.NET Routingの役割とは何か


ASP.NET Routingの役割は2つあります.
  • は、要求からデータを取得する.
  • は、データから仮想パスを生成する.
  • ASP.NET Routingの機能は双方向です.この2つの操作は厳密には非対称であることに注目すべきである.第1点は「要求」からデータをキャプチャするため、データソースは必ずしもURLではなく、Server Variables、Headerである可能性があります.これに対応して,データから生成される仮想パスは,必ずURL,文字列を生成する.
    普段ASPを使う.NET Routingの場合、ASPを大量に利用します.NET RoutingコンポーネントのRouteクラスは、Virtual Pathからデータを取得し、デフォルト値、制約などの高度な機能を提供する役割を果たします.ただし、ASPについてはNET Routingコンポーネント、あるいはその「エンジン」は抽象的なタイプの「RouteBase」を使用しています.RouteはRouteBaseの実現にすぎない.
    以前の記事では、FormatRouteやDomainRouteのような他の拡張子を提案しました.

    なぜRouteは正規表現を使用しないのか


    ASP.NET Routingに付属するRouteクラスは、指定したパステンプレートに基づいて、要求された仮想パスからデータを取得します.このテンプレートは、次のような形式です.
    {controller}/{action}/{id}
    これにより、現在要求されている仮想パスに基づいて、controller、action、idの3つの値がキャプチャされます.しかし、なぜ正規表現を使ってデータをキャプチャしないのかという友人がいます.例:
    (?\w+)/(?\w+)/(?\d+)
    名前付きキャプチャグループの正規表現を使用してパスを仮想化すると、controller、action、idの値も自然に得られます.さらに、正規表現を使用するもう1つの利点は、パス内の文字を厳格に制約できることです.たとえば、上記の正規表現はcontrollerとactionを単語文字に制限し、idを数字に制限することで、この形式を満たさないパスが一致しません.しかし、問題はどこにあるのでしょうか.
    ここでの問題はASPです.NET Routingの仕事は双方向ですが、正規表現を使うとデータをキャプチャするのはもちろんですが、正規表現から文字列を生成するのは容易ではありません.正規表現のマッチング形式が非常に広いため、逆方向に文字列を得ることができないことも多いです.したがって、値をコンストレイントする場合は、Routeオブジェクトにコンストレイント条件を1つしか指定できません.
    new { controller = "\w+", action="\w+", id="\d+" }
    もちろん、必要に応じて正規表現マッチングルールのサブセットを実装し、文字列を生成する作業を実行できるようにすることも問題ありません.

    ASP.NET Routingワークフロー


    ASP.NET Routingの作業には,要求の処理と仮想パスの生成の2つの側面がある.リクエスト処理時の流れはすでに前の記事で詳しく述べていますが、ここではASPについてもう一度お話しします.NET Routingが仮想パスを生成する方法.
    ASP.NET Routingは仮想パスを生成する際にRouteCollectionタイプの方法を使うのか、もちろんRouteTableのようなものです.Routesプロパティに登録されているRoutingルールは、自然にRouteTableからも登録されています.Routesプロパティで仮想パスを取得します.RouteCollectionタイプにはGetVirtualPathメソッドがあり、最終的に得られる仮想パスであるVirtualPathDataオブジェクトを返します.
    GetVirtualPathメソッドには、次の2つのリロードがあります.
    public VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values)
    RequestContextオブジェクトは現在のリクエストのコンテキストであり、RouteValueDictionaryには仮想パスを構築するためのデータが含まれています.要求の処理と同様に、RouteCollectionタイプのGetVirtualPathメソッドは、各RouteBaseオブジェクトのGetVirtualPathメソッドを順次呼び出し、nullでない最初の結果を返します(実際には処理も行われますが、以下を参照).RouteBaseオブジェクトが現在提供されているデータと一致しない場合、RouteCollectionのGetVirtualPathはnullを返します.
    GetVirtualPathメソッドの別のリロードでは、nameパラメータが提供されます.
    public VirtualPathData GetVirtualPath(RequestContext requestContext, string name, RouteValueDictionary values)
    nameパラメータの役割は、Routingルール、すなわち特定のRouteBaseオブジェクトを「指定」することです.このRouteBaseオブジェクトがnullを返すと、GetVirtualPathメソッドはnullを直接返します.名前を指定する利点は、コードの読み取りが高いこと(開発者が対応するRoutingポリシーを直接見つけることができる)、パフォーマンスに一定の利点(各Routingルールを遍歴する必要がない)、およびRoutingルール間で競合が発生しないことです.

    ASP.NET Routingはドメイン名をサポートしていますか?


    サポートされていません.設計からサポートされていません.
    この点は、RouteCollectionのGetVirtualPathメソッドの実装から分かるように、このメソッドは、各RouteBaseオブジェクトを巡回してnullでない最初の結果を得た後、すぐに戻るのではなく、GetUrlWithApplicationPathメソッドを使用して処理されます.
    private static string GetUrlWithApplicationPath(RequestContext requestContext, string url)
    {
        string str = requestContext.HttpContext.Request.ApplicationPath ?? string.Empty;
        if (!str.EndsWith("/", StringComparison.OrdinalIgnoreCase))
        {
            str = str + "/";
        }
    
        return requestContext.HttpContext.Response.ApplyAppPathModifier(str + url);
    }
    urlパラメータは「仮想パス」を意味し、GetUrlWithApplicationPathメソッドは「アプリケーションディレクトリ」を追加する役割を果たします.たとえば、私たちのサイトは「/」ではなく、「/MvcApp」という「サブサイト」に配備されている可能性があります.このように,RouteBaseのGetVirtualPathは仮想パス「Home/index/5」を返すが,RouteCollectionのGetVirtualPath手法はGetUrlWithApplicationPath処理を用いた後,最終的に戻るパスは/MvcApp/Home/index/5という文字列である.
    つまりASP.NET Routingは設計上ドメイン名の概念をサポートしておらず,RouteBaseオブジェクトを拡張できるが,RouteCollectionのGetVirtualPathメソッドを拡張することはできない.つまり、私たちのDomainRouteが似たようなものを返すことができても」http://www.cnblogs.com/HomeこのようなURLは、RouteCollectionのGetVirtualPath法によって鼓動され、前にスラッシュが加わる--従って、MvcPatchのMvcPatch.Routingプロジェクトでは、URLがhttpまたはhttpで始まる場合、アプリケーションディレクトリに接続されないGetVirtualPathExという拡張方法をRouteCollectionに提供しました.他の場合については,従来のGetVirtualPath法と一致した挙動を示した.
    DomainRouteを使用する場合は、従来のGetVirtualPathExメソッドではなくGetVirtualPathExを使用する必要があります.