ASP.NET Core'de yönlendirme

Yönlendirme, gelen HTTP isteklerini eşleştirmeden ve bu istekleri uygulamanın yürütülebilir uç noktalarına göndermeden sorumludur. Uç noktalar, uygulamanın yürütülebilir istek işleme kodu birimleridir. Uç noktalar uygulamada tanımlanır ve uygulama başlatıldığında yapılandırılır. Uç nokta eşleştirme işlemi, isteğin URL'lerinden değerleri ayıklar ve istek işleme için bu değerleri sağlar. Yönlendirme, uygulamanın uç nokta bilgilerini kullanarak uç noktalara eşlene URL'ler de oluşturabilecektir.

Uygulamalar şunları kullanarak yönlendirmeyi yapılandırabilirsiniz:

• Denetleyiciler
• Razor Sayfa
• SignalR
• gRPC Services
• Sistem Durumu Denetimleri gibi uç nokta özellikli ara yazılım.
• Yönlendirmeye kayıtlı temsilciler ve lambda'lar.

Bu belge, yönlendirmeyle ilgili alt düzey ASP.NET Core kapsar. Yönlendirmeyi yapılandırma hakkında bilgi için:

• Denetleyiciler için ASP.NET Core denetleyici eylemlerine yönlendirme bkz. .
• Sayfalar Razor kuralları için RazorSayfalarda yönlendirme ve uygulama kuralları ASP.NET Core bkz. .

Bu belgede açıklanan uç nokta yönlendirme sistemi, 3.0 ve ASP.NET Core için geçerlidir. tabanlı önceki yönlendirme sistemi hakkında bilgi IRouter için, aşağıdaki yaklaşımlardan ASP.NET Core 2.1 sürümünü seçin:

• Önceki bir sürümün sürüm seçicisi.
• 2.1 ASP.NET Core seçin.

Örnek kodu görüntüleme veya indirme ( nasılindir)

Bu belgenin indirme örnekleri belirli bir sınıf tarafından Startup etkinleştirilir. Belirli bir örneği çalıştırmak için Program.cs'yi istenen sınıfı çağıracak şekilde Startup değiştirebilirsiniz.

Yönlendirmenin temelleri

Tüm ASP.NET Core oluşturulan kodda yönlendirmeyi içerir. Yönlendirme, içinde ara yazılım işlem hattına Startup.Configure kaydedilir.

Aşağıdaki kod, temel bir yönlendirme örneği gösterir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Yönlendirme, ve tarafından kaydedilen bir ara yazılım çiftini UseRouting UseEndpoints kullanır:

• UseRouting ara yazılım işlem hattına yol eşleştirme ekler. Bu ara yazılım, uygulamada tanımlanan uç nokta kümesine bakarak i isteği temel alarak en iyi eşleşmeyi seçer.
• UseEndpoints ara yazılım işlem hattına uç nokta yürütme ekler. Seçilen uç noktayla ilişkili temsilciyi çalıştırır.

Yukarıdaki örnek, MapGet yöntemini kullanarak kod uç noktasına tek bir yol içerir:

• Kök GET URL'ye bir HTTP isteği gönder / geldiğinde:
  • Gösterilen istek temsilcisi yürütülür.
  • Hello World! HTTP yanıtına yazılır. Varsayılan olarak kök URL'si / https://localhost:5001/ olur.
• İstek yöntemi yoksa veya GET kök URL / yoksa, hiçbir yol eşleşmez ve HTTP 404 döndürülür.

Uç Nokta

yöntemi MapGet bir uç nokta tanımlamak için kullanılır. Uç nokta şu şekilde olabilir:

• URL ve HTTP yöntemiyle eşleştirerek seçildi.
• Temsilcisi çalıştırarak yürütülür.

Uygulama tarafından eşlene ve yürütüle uç noktalar içinde UseEndpoints yapılandırılır. Örneğin, MapGet , MapPost ve benzer yöntemler istek temsilcilerini yönlendirme sistemine bağlar. Ek yöntemler, ASP.NET Core çerçeve özelliklerini yönlendirme sistemine bağlamak için kullanılabilir:

• Sayfalar Razor için Sayfaları Razor Eşleme
• Denetleyiciler için MapControllers
• MapHub <THub> for SignalR
• gRPC için MapGrpcService <TService>

Aşağıdaki örnekte, daha gelişmiş bir yol şablonuna sahip yönlendirmeyi gösterir:

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("/hello/{name:alpha}", async context =>
    {
        var name = context.Request.RouteValues["name"];
        await context.Response.WriteAsync($"Hello {name}!");
    });
});

Dize bir /hello/{name:alpha} yol şablonudur. Uç noktanın nasıl eş olduğunu yapılandırmak için kullanılır. Bu durumda şablon şu şekildedir:

• Gibi bir URL /hello/Ryan
• Ile başlayan ve ardından alfabetik karakter dizisi gelen herhangi bir URL /hello/ yolu. :alpha yalnızca alfabetik karakterlerle eşleşen bir yol kısıtlaması uygular. Yol kısıtlamaları bu belgenin devamlarında açıklanmıştır.

URL yolunun ikinci {name:alpha} bölümü:

• parametresine name bağlı.
• HttpRequest.RouteValues içinde yakalanır ve depolanır.

Bu belgede açıklanan uç nokta yönlendirme sistemi, 3.0 ASP.NET Core yenidir. Ancak, tüm ASP.NET Core aynı yol şablonu özelliklerini ve yol kısıtlamalarını destekler.

Aşağıdaki örnek, sistem durumu denetimleri ve yetkilendirme ile yönlendirmeyi gösterir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    // Matches request to an endpoint.
    app.UseRouting();

    // Endpoint aware middleware. 
    // Middleware can use metadata from the matched endpoint.
    app.UseAuthentication();
    app.UseAuthorization();

    // Execute the matched endpoint.
    app.UseEndpoints(endpoints =>
    {
        // Configure the Health Check endpoint and require an authorized user.
        endpoints.MapHealthChecks("/healthz").RequireAuthorization();

        // Configure another endpoint, no authorization requirements.
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Ingilizce dışındaki dillere çevrilmiş kod açıklamalarını görmek isterseniz, Bu GitHub tartışma sorununubize tanıyın.

Yukarıdaki örnekte şunların nasıl olduğu gösterildi:

• Yetkilendirme ara yazılımı yönlendirme ile kullanılabilir.
• Uç noktalar yetkilendirme davranışını yapılandırmak için kullanılabilir.

Çağrı MapHealthChecks bir durum denetimi uç noktası ekler. Bu RequireAuthorization çağrıya zincirleme, uç noktasına bir yetkilendirme ilkesi iliştirer.

çağrısı UseAuthentication ve kimlik doğrulaması ve yetkilendirme ara yazılımı UseAuthorization ekler. Bu ara yazılım, şunların için UseRouting ve UseEndpoints ara yazılımlarına yerleştirilir:

• tarafından hangi uç noktanın seçildi, UseRouting bkz. .
• Uç noktasına göndermeden UseEndpoints önce bir yetkilendirme ilkesi uygulama.

Uç nokta meta verileri

Yukarıdaki örnekte iki uç nokta vardır, ancak yalnızca durum denetimi uç noktasının ekli bir yetkilendirme ilkesi vardır. İstek, durum denetimi uç noktasıyla eşiliyorsa /healthz bir yetkilendirme denetimi gerçekleştirilir. Bu, uç noktaların ek verilere sahip olduğunu gösteriyor. Bu ek verilere uç nokta meta verileri denir:

• Meta veriler yönlendirmeyi fark eterek ara yazılım tarafından işlenebilir.
• Meta veriler herhangi bir .NET türünde olabilir.

Yönlendirme kavramları

Yönlendirme sistemi, güçlü uç nokta kavramını ekleyerek ara yazılım işlem hattının üzerine inşa ediliyor. Uç noktalar, uygulamanın yönlendirme, yetkilendirme ve herhangi bir sayıda uygulamanın sistemlerinden ayrı olan ASP.NET Core birimlerini temsil ediyor.

ASP.NET Core uç nokta tanımı

Bir ASP.NET Core uç nokta:

• Yürütülebilir dosya: RequestDelegate bir .
• Genişletilebilir: Meta veri koleksiyonuna sahiptir.
• Seçilebilir: İsteğe bağlı olarak, yönlendirme bilgileri içerir.
• Numaralandırılabilir: Uç nokta koleksiyonu, DI'den alarak EndpointDataSource listelenebilir.

Aşağıdaki kod, geçerli istekle eşleşen uç noktayı alma ve incelemeyi gösterir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();

    app.Use(next => context =>
    {
        var endpoint = context.GetEndpoint();
        if (endpoint is null)
        {
            return Task.CompletedTask;
        }
        
        Console.WriteLine($"Endpoint: {endpoint.DisplayName}");

        if (endpoint is RouteEndpoint routeEndpoint)
        {
            Console.WriteLine("Endpoint has route pattern: " +
                routeEndpoint.RoutePattern.RawText);
        }

        foreach (var metadata in endpoint.Metadata)
        {
            Console.WriteLine($"Endpoint has metadata: {metadata}");
        }

        return Task.CompletedTask;
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Uç nokta seçiliyse, 'den HttpContext alabilir. Özellikleri ince olabilir. Uç nokta nesneleri sabittir ve oluşturma sonrasında değiştirilemez. En yaygın uç nokta türü bir RouteEndpoint 'dır. RouteEndpoint yönlendirme sistemi tarafından seçilecek bilgileri içerir.

Yukarıdaki kodda uygulama. Kullanma, satır içinde ara yazılım yapılandırıyor.

Aşağıdaki kod, işlem hattında nerede çağrıldıklarından bağımsız olarak app.Use bir uç nokta olmadığını gösterir:

// Location 1: before routing runs, endpoint is always null here
app.Use(next => context =>
{
    Console.WriteLine($"1. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
    return next(context);
});

app.UseRouting();

// Location 2: after routing runs, endpoint will be non-null if routing found a match
app.Use(next => context =>
{
    Console.WriteLine($"2. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
    return next(context);
});

app.UseEndpoints(endpoints =>
{
    // Location 3: runs when this endpoint matches
    endpoints.MapGet("/", context =>
    {
        Console.WriteLine(
            $"3. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
        return Task.CompletedTask;
    }).WithDisplayName("Hello");
});

// Location 4: runs after UseEndpoints - will only run if there was no match
app.Use(next => context =>
{
    Console.WriteLine($"4. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
    return next(context);
});

Bu önceki örnek Console.WriteLine , bir uç noktanın seçili olup olmadığını gösteren deyimler ekliyor. Netlik açısından örnek, belirtilen uç noktaya bir görünen ad atar / .

Bu kodu, ekran URL 'SI ile çalıştırma / :

1. Endpoint: (null)
2. Endpoint: Hello
3. Endpoint: Hello

Bu kodu başka bir URL ile çalıştırmak şunları görüntüler:

1. Endpoint: (null)
2. Endpoint: (null)
4. Endpoint: (null)

Bu çıkış şunları gösterir:

• Bitiş noktası, çağrılmadan önce her zaman null olur UseRouting .
• Bir eşleşme bulunursa, uç nokta ve arasında boş değildir UseRouting UseEndpoints .
• UseEndpointsBir eşleşme bulunduğunda ara yazılım terminaldir . Terminal ara yazılımı bu belgede daha sonra tanımlanır.
• UseEndpointsYalnızca eşleşme bulunamadığında yürütme sonrasında ara yazılım.

UseRoutingAra yazılım, uç noktayı geçerli bağlama eklemek Için setendpoint yöntemini kullanır. UseRoutingAra yazılımı özel mantık ile değiştirmek ve uç noktaları kullanmanın avantajlarını almaya devam etmek mümkündür. Uç noktalar, ara yazılım gibi alt düzey bir temel 'tür ve yönlendirme uygulamasıyla birlikte aktarılmaz. Çoğu uygulamanın UseRouting özel mantık ile değiştirme gereksinimi yoktur.

UseEndpointsAra yazılım, ara yazılım ile birlikte kullanılmak üzere tasarlanmıştır UseRouting . Bir uç noktayı yürütmek için çekirdek mantık karmaşık değildir. GetEndpointUç noktayı almak için kullanın ve ardından RequestDelegate özelliğini çağırın.

Aşağıdaki kod, ara yazılımların yönlendirmeyi nasıl etkileyebileceğini veya tepki vermesini gösterir:

public class IntegratedMiddlewareStartup
{ 
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        // Location 1: Before routing runs. Can influence request before routing runs.
        app.UseHttpMethodOverride();

        app.UseRouting();

        // Location 2: After routing runs. Middleware can match based on metadata.
        app.Use(next => context =>
        {
            var endpoint = context.GetEndpoint();
            if (endpoint?.Metadata.GetMetadata<AuditPolicyAttribute>()?.NeedsAudit
                                                                            == true)
            {
                Console.WriteLine($"ACCESS TO SENSITIVE DATA AT: {DateTime.UtcNow}");
            }

            return next(context);
        });

        app.UseEndpoints(endpoints =>
        {         
            endpoints.MapGet("/", async context =>
            {
                await context.Response.WriteAsync("Hello world!");
            });

            // Using metadata to configure the audit policy.
            endpoints.MapGet("/sensitive", async context =>
            {
                await context.Response.WriteAsync("sensitive data");
            })
            .WithMetadata(new AuditPolicyAttribute(needsAudit: true));
        });

    } 
}

public class AuditPolicyAttribute : Attribute
{
    public AuditPolicyAttribute(bool needsAudit)
    {
        NeedsAudit = needsAudit;
    }

    public bool NeedsAudit { get; }
}

Yukarıdaki örnekte iki önemli kavram gösterilmektedir:

• Ara yazılım, yönlendirmenin çalıştığı verileri değiştirmeden önce çalışabilir UseRouting .
  • Genellikle, yönlendirme öncesinde görünen ara yazılım, veya gibi, isteğin bazı özelliğini değiştirir UseRewriter UseHttpMethodOverride UsePathBase .
• Ara yazılım, ve arasında çalıştırılabilir UseRouting ve UseEndpoints uç nokta yürütülmeden önce yönlendirmenin sonuçlarını işleyebilir.
  • Ve arasında çalışan ara UseRouting yazılımlar UseEndpoints :
    • Genellikle uç noktaları anlamak için meta verileri inceler.
    • , Ve tarafından yapıldığı gibi genellikle güvenlik kararları UseAuthorization verir UseCors .
  • Ara yazılım ve meta verilerin birleşimi, ilkelerin uç nokta başına yapılandırılmasını sağlar.

Yukarıdaki kodda, uç nokta başına ilkeleri destekleyen özel bir ara yazılım örneği gösterilmektedir. Ara yazılım, gizli verilere erişim denetim günlüğünü konsola yazar. Ara yazılım, meta verileri olan bir uç noktayı denetlemek üzere yapılandırılabilir AuditPolicyAttribute . Bu örnek, yalnızca hassas olarak işaretlenen bitiş noktalarının denetlendiği bir katılım modelini gösterir. Örneğin, güvenli olarak işaretlenmemiş her şeyi denetlemek için bu mantığı ters olarak tanımlamak mümkündür. Uç nokta meta veri sistemi esnektir. Bu mantık, kullanım örneğine uygun herhangi bir şekilde tasarlanabilir.

Önceki örnek kod, uç noktaların temel kavramlarını göstermek için tasarlanmıştır. Örnek, üretim kullanımı için tasarlanmamıştır. Denetim günlüğü ara yazılımı 'nın daha kapsamlı bir sürümü şöyle olacaktır:

• Bir dosya veya veritabanında oturum açın.
• Kullanıcı, IP adresi, hassas bitiş noktasının adı ve daha fazlası gibi ayrıntıları dahil edin.

Denetim ilkesi meta verileri, AuditPolicyAttribute Attribute denetleyiciler ve gibi sınıf tabanlı çerçeveler ile daha kolay kullanılmak üzere tanımlanır SignalR . Kod yolu kullanırken:

• Meta veriler bir Oluşturucu API 'siyle birlikte eklenir.
• Sınıf tabanlı çerçeveler, uç noktalar oluştururken karşılık gelen Yöntem ve sınıftaki tüm öznitelikleri içerir.

Meta veri türleri için en iyi uygulamalar, bunları arabirimler ya da öznitelikler olarak tanımlamaktır. Arabirimler ve öznitelikler kod yeniden kullanılmasına izin verir. Meta veri sistemi esnektir ve herhangi bir kısıtlama vermez.

Terminal ara yazılımını ve yönlendirmeyi karşılaştırma

Aşağıdaki kod örneği, yönlendirmeyi kullanarak ara yazılım kullanarak karşıtlıkları:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    // Approach 1: Writing a terminal middleware.
    app.Use(next => async context =>
    {
        if (context.Request.Path == "/")
        {
            await context.Response.WriteAsync("Hello terminal middleware!");
            return;
        }

        await next(context);
    });

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        // Approach 2: Using routing.
        endpoints.MapGet("/Movie", async context =>
        {
            await context.Response.WriteAsync("Hello routing!");
        });
    });
}

İle gösterilen ara yazılım stili, Approach 1: Terminal ara yazılımı. Bu, eşleşen bir işlem yaptığı için Terminal ara yazılımı olarak adlandırılır:

• Yukarıdaki örnekteki eşleştirme işlemi, Path == "/" Ara yazılım ve Path == "/Movie" yönlendirme içindir.
• Bir eşleşme başarılı olduğunda, ara yazılımı çağırmak yerine bazı işlevleri yürütür ve döndürür next .

Bu, aramayı sonlandırdığı, bazı işlevleri yürüttüğünde ve sonra döndürdüğünden, Terminal ara yazılımı olarak adlandırılır.

Terminal ara yazılımını ve yönlendirmeyi karşılaştırma:

• Her iki yaklaşım da işleme ardışık düzeninin sonlandırılmasını sağlar:
  • Ara yazılım, komut zinciri çağırmak yerine dönerek işlem hattını sonlandırır next .
  • Uç noktalar her zaman terminaldir.
• Terminal ara yazılımı, işlem hattındaki ara yazılımı rastgele bir yerde konumlandırmayı sağlar:
  • Uç noktalar, konumunda yürütülür UseEndpoints .
• Terminal ara yazılımı, rastgele kodun, ara yazılımın ne zaman eşleştiğini belirlemesine izin verir:
  • Özel yol eşleştirme kodu ayrıntılı ve doğru yazılması zor olabilir.
  • Yönlendirme, tipik uygulamalar için doğrudan çözümler sağlar. Çoğu uygulama özel yol eşleştirme kodu gerektirmez.
• Ve gibi ara yazılım içeren uç noktalar arabirimi UseAuthorization UseCors .
  • Veya ile Terminal ara yazılımı UseAuthorization kullanmak UseCors , yetkilendirme sistemiyle el ile arabirim oluşturma gerektirir.

Bir uç nokta her ikisini de tanımlar:

• İstekleri işlemek için bir temsilci.
• Rastgele meta veri koleksiyonu. Meta veriler, her uç noktaya eklenen ilkelere ve yapılandırmaya göre çapraz kesme sorunları uygulamak için kullanılır.

Terminal ara yazılımı etkin bir araç olabilir, ancak şunları gerektirebilir:

• Önemli miktarda kodlama ve test.
• İstenen esneklik düzeyine ulaşmak için diğer sistemlerle el ile tümleştirme.

Terminal ara yazılımı yazmadan önce yönlendirme ile tümleştirmeyi düşünün.

Eşleme ile tümleştirilen mevcut Terminal ara yazılımı MapWhen , genellikle bir yönlendirme duyarlı uç noktaya açılabilir. Maphealthdenetimleri , yönlendirici-Ware için bir model gösterir:

• Üzerine bir genişletme yöntemi yazın IEndpointRouteBuilder .
• Kullanarak iç içe geçmiş bir ara yazılım işlem hattı oluşturun CreateApplicationBuilder .
• Yeni işlem hattına ara yazılım ekleyin. Bu durumda, UseHealthChecks .
• Build içinde bir ara yazılım ardışık düzeni RequestDelegate .
• Map' İ çağırın ve yeni ara yazılım ardışık düzenini sağlayın.
• Uzantı yönteminden tarafından sunulan Oluşturucu nesnesini döndürün Map .

Aşağıdaki kod, Maphealthdenetimlerininkullanımını gösterir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    // Matches request to an endpoint.
    app.UseRouting();

    // Endpoint aware middleware. 
    // Middleware can use metadata from the matched endpoint.
    app.UseAuthentication();
    app.UseAuthorization();

    // Execute the matched endpoint.
    app.UseEndpoints(endpoints =>
    {
        // Configure the Health Check endpoint and require an authorized user.
        endpoints.MapHealthChecks("/healthz").RequireAuthorization();

        // Configure another endpoint, no authorization requirements.
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Yukarıdaki örnek, Oluşturucu nesnesinin neden önemli olduğunu gösterir. Oluşturucu nesnesini döndürmek, uygulama geliştiricisinin uç nokta için yetkilendirme gibi ilkeleri yapılandırmasına izin verir. Bu örnekte, sistem durumu denetimleri ara yazılımı yetkilendirme sistemiyle doğrudan tümleştirme gerektirmez.

Meta veri sistemi, Terminal ara yazılımı kullanan genişletilebilirlik yazarları tarafından karşılaşılan sorunlara yanıt olarak oluşturulmuştur. Her bir ara yazılım, yetkilendirme sistemiyle kendi tümleştirmesini uygulamak için sorunlu olur.

URL eşleştirme

• , Yönlendirmenin bir uç noktayagelen istekle eşleştiği işlemdir.
• URL yolu ve üst bilgilerindeki verileri temel alır.
• İstekteki verileri göz önünde bulundurmanız için genişletilebilir.

Bir yönlendirme ara yazılımı yürütüldüğünde, Endpoint geçerli istekten ' de bir istek özelliğine bir ve rota değeri ayarlar HttpContext :

• HttpContext. GetEndpoint çağrısı uç noktasını alır.
• HttpRequest.RouteValues yol değerlerinin koleksiyonunu alır.

Yönlendirme ara yazılımı , çalışan ara yazılım uç noktasını inceleyebilir ve işlem yapabilir. Örneğin, bir yetkilendirme ara yazılımı, bir yetkilendirme ilkesi için bitiş noktasının meta veri koleksiyonunu sorgulanamıyor. İstek işleme ardışık düzeninde bulunan tüm ara yazılım yürütüldükten sonra, seçilen uç noktanın temsilcisi çağrılır.

Uç nokta yönlendirmesinde yönlendirme sistemi tüm gönderme kararlarından sorumludur. Ara yazılım, seçili uç noktaya göre ilkeler uyguladığı için şu önemlidir:

• Güvenlik ilkelerinin dağıtımını etkileyebilecek herhangi bir karar, yönlendirme sisteminin içinde yapılır.

URL eşleştirme yapılandırılabilir bir aşama kümesinde çalışır. Her aşamada çıkış bir eşleşme kümesidir. Eşleşme kümesi, bir sonraki aşamaya kadar daha fazla daraltıladır. Yönlendirme uygulaması, eşleşen uç noktalar için bir işleme sırası garanti değildir. Tüm olası eşleşmeler aynı anda işlenir. URL eşleştirme aşamaları aşağıdaki sırayla gerçekleşir. ASP.NET Core:

1. TÜM eşleşmeleri toplayarak URL yolunu uç noktalar kümesine ve yol şablonlarına göre işler.
2. Önceki listeyi alır ve rota kısıtlamaları uygulanmış olarak başarısız olan eşleşmeleri kaldırır.
3. Önceki listeyi alır ve MatcherPolicy örnekleri kümesi başarısız olan eşleşmeleri kaldırır.
4. Önceki listeden son bir karara varma için EndpointSelector'ı kullanır.

Uç noktaların listesi aşağıdakilere göre öncelik sırasına göredir:

• RouteEndpoint.Order
• Yol şablonu önceliği

Eşleşen tüm uç noktalar, ulaşana kadar her EndpointSelector aşamada işlenir. EndpointSelector, son aşamadır. En iyi eşleşme olarak eşleşmelerden en yüksek öncelikli uç noktayı seçer. En iyi eşleşmeyle aynı önceliğe sahip başka eşleşmeler varsa, belirsiz bir eşleşme özel durumu oluşturur.

Yol önceliği, daha yüksek önceliğe sahip olan daha belirli bir yol şablonuna göre hesaplanır. Örneğin, ve şablonlarını göz önünde /hello /{message} bulundurabilirsiniz:

• Her ikisi de URL yolu ile /hello eştir.
• /hello daha özeldir ve bu nedenle daha yüksek önceliklidir.

Genel olarak, yol önceliği uygulamada kullanılan URL şeması türleri için en iyi eşleşmeyi seçmeye iyi bir iş yapar. Belirsizlikten Order kaçınmak için yalnızca gerekli olduğunda kullanın.

Yönlendirme tarafından sağlanan genişletilebilirlik türleri nedeniyle, yönlendirme sisteminin belirsiz yolları zamanından önce hesaplaması mümkün değildir. Yol şablonları ve gibi bir örneği göz önünde /{message:alpha} /{message:int} bulundurabilirsiniz:

• Kısıtlama alpha yalnızca alfabetik karakterlerle eşler.
• Kısıtlama int yalnızca sayılarla eştir.
• Bu şablonlar aynı yol önceliğe sahip ancak her ikisi de eşleşen tek bir URL yoktur.
• Yönlendirme sistemi başlangıçta bir belirsizlik hatası bildirse, bu geçerli kullanım durumunu engelleyebilir.

Rota şablonu önceliği ve uç nokta seçim sırası

Yol şablonu önceliği, her yol şablonunun ne kadar özel olduğunu temel alan bir değer ataan bir sistemdir. Rota şablonu önceliği:

• Yaygın durumlarda uç noktaların sıralarını ayarlama ihtiyacının önüne geçebilirsiniz.
• Yönlendirme davranışının genel anlamda beklentileriyle eşleşmeye çalışır.

Örneğin, ve şablonlarını göz önünde /Products/List /Products/{id} bulundurabilirsiniz. Bunun URL yoluna göre daha /Products/List iyi bir eşleşme olduğunu /Products/{id} /Products/List varsayabilirsiniz. Bu, değişmez değer segmentinin parametre kesimine göre daha iyi /List bir önceliğe sahip olduğu kabul edilir. /{id}

Önceliğin nasıl çalıştığının ayrıntıları, yol şablonlarının nasıl tanımlandığıyla birtir:

• Daha fazla segmente sahip şablonlar daha belirli olarak kabul edilir.
• Değişmez değer metnine sahip bir segment, parametre kesimine göre daha belirli olarak kabul edilir.
• Kısıtlaması olan bir parametre kesimi, olmadan birden fazla özel olarak kabul edilir.
• Karmaşık bir kesim, kısıtlaması olan bir parametre segmenti olarak belirli olarak kabul edilir.
• Tüm catch parametreleri en az belirlidir. Catch-all rotaları hakkında önemli bilgiler için Yol şablonu başvurusunda hepsini yakalama'ya bakın.

Tam değer başvurusu için GitHub kaynak koduna bakın.

URL oluşturma kavramları

URL oluşturma:

• Yönlendirmenin bir yol değerleri kümesine dayalı bir URL yolu oluşturma işlemidir.
• Uç noktalar ve onlara erişen URL'ler arasında mantıksal bir ayrım sağlar.

Uç nokta yönlendirme API'sini LinkGenerator içerir. LinkGenerator, DI'den kullanılabilen tek bir hizmettir. LinkGeneratorAPI, yürütülen bir isteğin bağlamı dışında kullanılabilir. Mvc.IUrlHelper ve Etiket Yardımcıları, HTML Yardımcıları ve Eylem Sonuçları gibi kullanan senaryolar, bağlantı oluşturma özellikleri sağlamak için IUrlHelper LinkGenerator API'yi dahili olarak kullanır.

Bağlantı oluşturucu, adres ve adres şemaları kavramı tarafından de yedekler. Adres düzeni, bağlantı oluşturma için dikkate alınacak uç noktaları belirlemenin bir yolu olarak kabul edilir. Örneğin, birçok kullanıcının denetleyicilerden aşina olduğu yol adı ve yol değerleri senaryoları ve Razor Sayfalar bir adres düzeni olarak uygulanır.

Bağlantı oluşturucu, aşağıdaki genişletme yöntemleri aracılığıyla Razor denetleyicilere ve Sayfalara bağlantı kullanabilir:

• GetPathByAction
• GetUriByAction
• GetPathByPage
• GetUriByPage

Bu yöntemlerin aşırı yüklemeleri, içeren bağımsız değişkenleri kabul HttpContext eder. Bu yöntemler, Url.Action ile işlevsel olarak eşdeğerdir ve Url.Pageesneklik ve seçenekler sunar.

yöntemleri, GetPath* mutlak yol içeren bir Url.Action URI oluşturmaları için en çok ve Url.Page yöntemlerine benzer. Yöntemler GetUri* her zaman bir şema ve ana bilgisayar içeren mutlak bir URI üretir. Kabul eden HttpContext yöntemler, yürütme isteği bağlamında bir URI üretir. Geçersiz kılınmadıkça, ortam yolu değerleri, URL temel yolu, şema ve yürütme isteğinden konak kullanılır.

LinkGenerator adresiyle çağrılır. URI oluşturma iki adımda gerçekleşir:

1. Adres, adresle eşan bir uç nokta listesine bağlı.
2. Her uç RoutePattern noktanın değerleri, sağlanan değerlerle eşleşen bir yol deseni bulunana kadar değerlendirilir. Sonuçta elde edilen çıkış, bağlantı oluşturucuya sağlanan ve döndürülen diğer URI bölümleriyle bir araya gelir.

Tarafından sağlanan yöntemler, LinkGenerator herhangi bir adres türü için standart bağlantı oluşturma özelliklerini destekler. Bağlantı oluşturucu kullanmanın en kolay yolu, belirli bir adres türü için işlem gerçekleştiren genişletme yöntemleridir:

Ara yazılım örneği

Aşağıdaki örnekte ara yazılım, mağaza ürünlerini listeleyen bir eylem LinkGenerator yönteminin bağlantısını oluşturmak için API'yi kullanır. Bağlantı oluşturucusünü bir sınıfa ek olarak kullanarak ve çağrısı GenerateLink bir uygulamanın herhangi bir sınıfı tarafından kullanılabilir:

public class ProductsLinkMiddleware
{
    private readonly LinkGenerator _linkGenerator;

    public ProductsLinkMiddleware(RequestDelegate next, LinkGenerator linkGenerator)
    {
        _linkGenerator = linkGenerator;
    }

    public async Task InvokeAsync(HttpContext httpContext)
    {
        var url = _linkGenerator.GetPathByAction("ListProducts", "Store");

        httpContext.Response.ContentType = "text/plain";

        await httpContext.Response.WriteAsync($"Go to {url} to see our products.");
    }
}

Rota şablonu başvurusu

içindeki {} belirteçler, yol eşlenirken bağlı olan yol parametrelerini tanımlar. Yol segmentinde birden fazla yol parametresi tanımlanabilir, ancak yol parametreleri bir sabit değer ile ayrılmalıdır. Örneğin, {controller=Home}{action=Index} ve arasında değişmez değer olmadığından geçerli bir yol değil {controller} {action} . Rota parametrelerinin bir adı olmalı ve ek öznitelikler belirtilmiş olabilir.

Yol parametrelerinden (örneğin, {id} ) ve yol ayırıcısından farklı bir metin, / URL içindeki metinle eşleşmelidir. Metin eşleştirme, büyük/küçük harfe duyarsız ve URL 'nin yolunun kodu çözülmüş gösterimine göre yapılır. Sabit bir yol parametresi sınırlayıcısından eşlemek { veya } karakteri tekrarlayarak sınırlayıcıdan kaçış. Örneğin {{ veya }} .

Yıldız işareti * veya çift yıldız işareti ** :

• URI 'nin geri kalanına bağlamak için bir yol parametresinin öneki olarak kullanılabilir.
• , Catch-all parametreleri olarak adlandırılır. Örneğin blog/{**slug} :
  • İle başlayan /blog ve bundan sonraki bir değere sahip tüm URI ile eşleşir.
  • Aşağıdaki değer, /blog başlık yolu değerine atanır.

public static void Main(string[] args)
{
   AppContext.SetSwitch("Microsoft.AspNetCore.Routing.UseCorrectCatchAllBehavior", 
                         true);
   CreateHostBuilder(args).Build().Run();
}
// Remaining code removed for brevity.

Catch-all parametreleri boş dizeyle de aynı olabilir.

Catch-all parametresi, yol ayırıcı karakterleri de dahil olmak üzere bir URL oluşturmak için kullanıldığında uygun karakterlerin bir kaçar / . Örneğin, foo/{*path} yol değerlerini içeren yol { path = "my/path" } oluşturulur foo/my%2Fpath . Atlanan eğik çizgiye göz önünde edin. Yol ayırıcı karakterlerini yuvarlaklaştırmak için ** Rota parametresi önekini kullanın. İle rota foo/{**path} { path = "my/path" } oluşturulur foo/my/path .

İsteğe bağlı bir dosya uzantısına sahip bir dosya adı yakalamaya deneyen URL desenlerinin ek konuları vardır. Örneğin, şablonu göz önünde bulundurun files/{filename}.{ext?} . Hem hem de için değerler olduğunda filename ext her iki değer de doldurulur. URL 'de yalnızca bir değeri filename varsa, sondaki değer isteğe bağlı olduğundan yol eşleşir . . Aşağıdaki URL 'Ler bu rota ile eşleşiyor:

• /files/myFile.txt
• /files/myFile

Yol parametreleri, parametre adından sonra bir eşittir işaretiyle () ayırarak varsayılan değer belirtilerek belirlenmiş varsayılan değerlere sahip olabilir = . Örneğin, {controller=Home} Home için varsayılan değer olarak tanımlar controller . Parametresi için URL 'de hiçbir değer yoksa varsayılan değer kullanılır. Yol parametreleri, parametre adının sonuna bir soru işareti () eklenerek isteğe bağlı olarak yapılır ? . Örneğin, id?. İsteğe bağlı değerler ve varsayılan yol parametreleri arasındaki fark şudur:

• Varsayılan değere sahip bir yol parametresi her zaman bir değer üretir.
• İsteğe bağlı bir parametre yalnızca istek URL 'SI tarafından bir değer sağlandığında bir değere sahip olur.

Rota parametrelerinin URL 'den bağlanan rota değeriyle eşleşmesi gereken kısıtlamaları olabilir. :Yol parametre adından sonra ekleme ve kısıtlama adı, bir rota parametresinde bir satır içi kısıtlamayı belirtir. Kısıtlama bağımsız değişkenler gerektiriyorsa, kısıtlama adından sonra parantez içine alınır (...) . Birden çok satır içi kısıtlama , başka bir : kısıtlama adı eklenerek belirtilebilir.

Kısıtlama adı ve bağımsız değişkenler, IInlineConstraintResolver IRouteConstraint URL işlemede kullanılmak üzere bir örneği oluşturmak için hizmetine geçirilir. Örneğin, yol şablonu blog/{article:minlength(10)} minlength bağımsız değişkenle bir kısıtlama belirtir 10 . Yol kısıtlamaları ve Framework tarafından sunulan kısıtlamaların bir listesi hakkında daha fazla bilgi için, route kısıtlama başvurusu bölümüne bakın.

Rota parametrelerinin ayrıca parametre dönüştürücüler de olabilir. Parametre dönüştürücüler, URL 'Ler için bağlantılar ve eşleşen eylemler ve sayfalar oluştururken parametrenin değerini dönüştürür. Benzer kısıtlamalar, : yol parametre adından sonra bir ve transformatör adı eklenerek, parametre dönüştürücüleri bir rota parametresine satır içi eklenebilir. Örneğin, yol şablonu blog/{article:slugify} bir slugify transformatör belirtir. Parametre dönüştürücüler hakkında daha fazla bilgi için bkz. Parameter transformatör başvurusu bölümü.

Aşağıdaki tabloda örnek yol şablonları ve bunların davranışları gösterilmektedir:

Bir şablon kullanmak genellikle yönlendirmeye en basit yaklaşımdır. Kısıtlamalar ve varsayılanlar, yol şablonu dışında da belirtilebilir.

Karmaşık segmentler

Karmaşık segmentler, en çok greksuz olmayan bir şekilde, sabit değer sınırlayıcılarını sağdan sola eşleştirerek işlenir. Örneğin, [Route("/a{b}c{d}")] karmaşık bir kesimdir. Karmaşık segmentler, onları başarılı bir şekilde kullanmak için anlaşılması gereken belirli bir şekilde çalışır. Bu bölümdeki örnek, sınırlayıcı metnin parametre değerleri içinde görünmemesinin neden karmaşık segmentlerin gerçekten iyi şekilde çalıştığını gösterir. Bir Regex kullanarak ve daha karmaşık durumlar için değerleri el ile ayıklamanız gerekir.

Bu, yönlendirmenin şablon ve URL yolu ile gerçekleştirdiği adımların bir özetidir /a{b}c{d} /abcd . , | Algoritmanın nasıl çalıştığını görselleştirmeye yardımcı olmak için kullanılır:

• İlk sabit değer, sağdan sola c . Bu nedenle /abcd , doğru bir şekilde aranır ve bulur /ab|c|d .
• Right () öğesine ait her şey d artık Route parametresiyle eşleştirildi {d} .
• Sonraki değişmez değer, sağdan sola a . Bu nedenle /ab|c|d , ayrıldığımız yerden başlayarak arama yapılır a /|a|b|c|d .
• Right ( b ) değeri artık Route parametresiyle eşleştirildi {b} .
• Kalan bir metin yok ve kalan yol şablonu yok, bu nedenle bu bir eşleşmedir.

Aynı şablonu ve URL yolunu kullanarak negatif bir durum örneği aşağıda verilmiştir /a{b}c{d} /aabcd . , | Algoritmanın nasıl çalıştığını görselleştirmeye yardımcı olmak için kullanılır. Bu durum, aynı algoritma tarafından açıklanan bir eşleşme değildir:

• İlk sabit değer, sağdan sola c . Bu nedenle /aabcd , doğru bir şekilde aranır ve bulur /aab|c|d .
• Right () öğesine ait her şey d artık Route parametresiyle eşleştirildi {d} .
• Sonraki değişmez değer, sağdan sola a . Bu nedenle /aab|c|d , ayrıldığımız yerden başlayarak arama yapılır a /a|a|b|c|d .
• Right ( b ) değeri artık Route parametresiyle eşleştirildi {b} .
• Bu noktada, kalan metin vardır a ancak algoritmanın ayrıştırılacak yol şablonu kalmadı, bu nedenle bu bir eşleşme değildir.

Eşleşen algoritma greyumsuzolmadığından:

• Her adımda mümkün olan en küçük metin miktarıyla eşleşir.
• Sınırlayıcı değerin parametre değerleri içinde göründüğü herhangi bir durum, eşleşmemelidir.

Normal ifadeler, eşleşen davranışları üzerinde çok daha fazla denetim sağlar.

Aynı zamanda yavaş eşleşmeolarak da bilinen Greedy eşleştirmesi, olası en büyük dizeyle eşleşir. Doyumsuz olmayan dize, olası en küçük dizeyle eşleşir.

Yol kısıtlama başvurusu

Yol kısıtlamaları, gelen URL 'de bir eşleşme meydana geldiğinde ve URL yolu yol değerlerinde simgeleştirilir yürütülür. Yol kısıtlamaları genellikle yol şablonu aracılığıyla ilişkili rota değerini inceler ve değerin kabul edilebilir olup olmadığı konusunda doğru veya yanlış bir karar vermez. Bazı rota kısıtlamaları, isteğin yönlendirilip yönlendirilmeyeceğini göz önünde bulundurmanız için yol değeri dışındaki verileri kullanır. Örneğin, HttpMethodRouteConstraint bir ISTEğI http fiiline bağlı olarak kabul edebilir veya reddedebilir. Kısıtlamalar, yönlendirme isteklerinde ve bağlantı oluşturmada kullanılır.

Aşağıdaki tabloda örnek yol kısıtlamaları ve beklenen davranışlar gösterilmektedir:

Birden çok, iki nokta üst üste sınırlı kısıtlama, tek bir parametreye uygulanabilir. Örneğin, aşağıdaki kısıtlama bir parametreyi 1 veya daha büyük bir tamsayı değeriyle kısıtlar:

[Route("users/{id:int:min(1)}")]
public User GetUserById(int id) { }

Kısıtlamalarda normal ifadeler

Normal ifadeler, Route kısıtlaması kullanılarak satır içi kısıtlamalar olarak belirtilebilir regex(...) . MapControllerRouteAilesindeki Yöntemler ayrıca Kısıtlamaların bir nesne sabit değerini de kabul eder. Bu form kullanılıyorsa, dize değerleri normal ifadeler olarak yorumlanır.

Aşağıdaki kod, bir satır içi Regex kısıtlaması kullanır:

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("{message:regex(^\\d{{3}}-\\d{{2}}-\\d{{4}}$)}",
        context => 
        {
            return context.Response.WriteAsync("inline-constraint match");
        });
 });

Aşağıdaki kod, bir Regex kısıtlaması belirtmek için bir nesne değişmez değeri kullanır:

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "people",
        pattern: "People/{ssn}",
        constraints: new { ssn = "^\\d{3}-\\d{2}-\\d{4}$", },
        defaults: new { controller = "People", action = "List", });
});

ASP.NET Core framework, RegexOptions.IgnoreCase | RegexOptions.Compiled | RegexOptions.CultureInvariant normal ifade oluşturucusuna ekler. RegexOptionsBu üyelerin açıklaması için bkz..

Normal ifadeler, Yönlendirme ve C# dili tarafından kullanılanlarla benzerlik olan sınırlayıcıları ve belirteçleri kullanır. Normal ifade belirteçlerinin atlanmalıdır. Normal ifadeyi ^\d{3}-\d{2}-\d{4}$ bir satır içi kısıtlamada kullanmak için aşağıdakilerden birini kullanın:

• Dizede \ belirtilen karakterleri, \\ dize kaçış karakterinden kaçınmak Için C# kaynak dosyasındaki karakter olarak değiştirin \ .
• Tam dize sabit değerleri.

Yönlendirme parametresi sınırlayıcı karakterlerini { ,,, } , [ ] ifadedeki karakterleri çift kaçış, örneğin {{ }} [[ ]] ,,,,. Aşağıdaki tabloda, bir normal ifade ve bunun kaçış sürümü gösterilmektedir:

Yönlendirmelerde kullanılan normal ifadeler, genellikle karakteriyle başlar ^ ve dizenin başlangıç konumuyla eşleşir. İfadeler genellikle $ karakteriyle biter ve dizenin sonuyla eşleşir. ^Ve $ karakterleri, normal ifadenin tüm yol parametresi değeri ile eşleştiğinden emin olun. ^Ve karakterleri olmadan $ normal ifade, dize içindeki herhangi bir alt dizeden eşleşir ve bu genellikle istenmeyen bir ifadedir. Aşağıdaki tabloda örnekler verilmektedir ve bunların eşleşmesinin neden eşleşmediği veya eşleşmemesi açıklanmaktadır:

normal ifade sözdizimi hakkında daha fazla bilgi için bkz. .NET Framework normal ifadeler.

Bir parametreyi bilinen olası değerler kümesiyle kısıtlamak için, normal bir ifade kullanın. Örneğin, {action:regex(^(list|get|create)$)} yalnızca action Rota değeri list ,, veya ile eşleşir get create . Kısıtlama sözlüğüne geçirilirse dize ^(list|get|create)$ eşdeğerdir. Bilinen kısıtlamalardan biriyle eşleşmeyen kısıtlama sözlüğünde geçirilen kısıtlamalar, normal ifadeler olarak da değerlendirilir. Bilinen kısıtlamaların biriyle eşleşmeyen bir şablon içinde geçirilen kısıtlamalar normal ifadeler olarak değerlendirilmez.

Özel yol kısıtlamaları

Özel yol kısıtlamaları arabirimi uygulayarak oluşturulabilir IRouteConstraint . IRouteConstraintArabirimi, Match true kısıtlama karşılanıp Aksi takdirde döndüren ' i içerir false .

Özel yol kısıtlamaları nadiren gereklidir. Özel bir yol kısıtlaması uygulamadan önce, model bağlama gibi alternatifleri göz önünde bulundurun.

ASP.NET Core kısıtlamalar klasörü, bir kısıtlama oluşturmaya yönelik iyi örnekler sağlar. Örneğin, Guidrouteconstraint.

Özel bir kullanmak için IRouteConstraint yol kısıtlama türü, uygulamanın hizmet kapsayıcısında kayıtlı olması gerekir ConstraintMap . ConstraintMap, Yol kısıtlama anahtarlarını IRouteConstraint Bu kısıtlamaları doğrulayan uygulamalarla eşleyen bir sözlüktür. Bir uygulama ConstraintMap , Startup.ConfigureServices hizmetlerin bir parçası olarak ' de güncelleştirilir . AddRouting çağrısı veya RouteOptions doğrudan ile yapılandırma services.Configure<RouteOptions> . Örnek:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    services.AddRouting(options =>
    {
        options.ConstraintMap.Add("customName", typeof(MyCustomConstraint));
    });
}

Önceki kısıtlama aşağıdaki kodda uygulanır:

[Route("api/[controller]")]
[ApiController]
public class TestController : ControllerBase
{
    // GET /api/test/3
    [HttpGet("{id:customName}")]
    public IActionResult Get(string id)
    {
        return ControllerContext.MyDisplayRouteInfo(id);
    }

    // GET /api/test/my/3
    [HttpGet("my/{id:customName}")]
    public IActionResult Get(int id)
    {
        return ControllerContext.MyDisplayRouteInfo(id);
    }
}

Mydisplayrouteınfo , Rick.Docs. Samples. routeınfo NuGet paketi tarafından sağlanır ve rota bilgilerini görüntüler.

Uygulamasının uygulanması, MyCustomConstraint 0 bir rota parametresine uygulanmasını engeller:

class MyCustomConstraint : IRouteConstraint
{
    private Regex _regex;

    public MyCustomConstraint()
    {
        _regex = new Regex(@"^[1-9]*$",
                            RegexOptions.CultureInvariant | RegexOptions.IgnoreCase,
                            TimeSpan.FromMilliseconds(100));
    }
    public bool Match(HttpContext httpContext, IRouter route, string routeKey,
                      RouteValueDictionary values, RouteDirection routeDirection)
    {
        if (values.TryGetValue(routeKey, out object value))
        {
            var parameterValueString = Convert.ToString(value,
                                                        CultureInfo.InvariantCulture);
            if (parameterValueString == null)
            {
                return false;
            }

            return _regex.IsMatch(parameterValueString);
        }

        return false;
    }
}

Yukarıdaki kod:

• Yolunun 0 {id} segmentinde önler.
• Özel kısıtlama uygulamanın temel bir örneğini sağlamak için gösterilir. Üretim uygulamasında kullanılmamalı.

Aşağıdaki kod, içeren bir içerenin işlenmesini id önlemeye yönelik daha 0 iyi bir yaklaşımdır:

[HttpGet("{id}")]
public IActionResult Get(string id)
{
    if (id.Contains('0'))
    {
        return StatusCode(StatusCodes.Status406NotAcceptable);
    }

    return ControllerContext.MyDisplayRouteInfo(id);
}

Yukarıdaki kod, yaklaşıma göre aşağıdaki avantajlara MyCustomConstraint sahiptir:

• Özel bir kısıtlama gerektirmez.
• Yol parametresi dahil olduğunda daha açıklayıcı bir hata 0 döndürür.

Parametre dönüştürücü başvurusu

Parametre dönüştürücüleri:

• kullanarak bağlantı oluşturmak için LinkGenerator yürütün.
• Microsoft.AspNetCore.Routing.IOutboundParameterTransformeruygulama.
• kullanılarak ConstraintMap yapılandırılır.
• Parametrenin yol değerini alıp yeni bir dize değerine dönüştür.
• Oluşturulan bağlantıda dönüştürülmüş değeri kullanarak sonuç elde edin.

Örneğin, ile rota düzeninde özel bir parametre dönüştürücü slugify blog\{article:slugify} Url.Action(new { article = "MyTestArticle" }) blog\my-test-article üretir.

Aşağıdaki uygulamaları göz önünde IOutboundParameterTransformer bulundurarak:

public class SlugifyParameterTransformer : IOutboundParameterTransformer
{
    public string TransformOutbound(object value)
    {
        if (value == null) { return null; }

        return Regex.Replace(value.ToString(), 
                             "([a-z])([A-Z])",
                             "$1-$2",
                             RegexOptions.CultureInvariant,
                             TimeSpan.FromMilliseconds(100)).ToLowerInvariant();
    }
}

Yol düzeninde parametre dönüştürücü kullanmak için içinde parametresini kullanarak ConstraintMap Startup.ConfigureServices yapılandırarak:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    services.AddRouting(options =>
    {
        options.ConstraintMap["slugify"] = typeof(SlugifyParameterTransformer);
    });
}

Bu ASP.NET Core, bir uç noktanın çözümlemesi gereken URI'yi dönüştürmek için parametre dönüştürücülerini kullanır. Örneğin, parametre dönüştürücüleri , , ve ile eşleşmek için kullanılan area controller yol değerlerini action page dönüştürer.

routes.MapControllerRoute(
    name: "default",
    template: "{controller:slugify=Home}/{action:slugify=Index}/{id?}");

Yukarıdaki yol şablonuyla, eylemi SubscriptionManagementController.GetAll URI'sı ile /subscription-management/get-all eştir. Parametre dönüştürücü, bağlantı oluşturmak için kullanılan yol değerlerini değiştirmez. Örneğin, Url.Action("GetAll", "SubscriptionManagement") çıkışını /subscription-management/get-all oluşturur.

ASP.NET Core yollarla parametre dönüştürücüleri kullanmak için API kuralları sağlar:

• Microsoft.AspNetCore.Mvc.ApplicationModels.RouteTokenTransformerConventionMVC kuralı, uygulamanın tüm öznitelik yollarında belirtilen parametre dönüştürücülerini uygular. parametresi dönüştürücü, değiştirildikleri şekilde öznitelik yol belirteçlerini dönüştürer. Daha fazla bilgi için bkz. Belirteç değişimini özelleştirmek için parametre dönüştürücü kullanma.
• Razor Sayfalar PageRouteTransformerConvention API kuralı kullanır. Bu kural, otomatik olarak bulunan tüm Sayfalara belirtilen bir parametre dönüştürücü Razor uygular. parametresi transformer, Sayfalar yollarının klasör ve dosya adı Razor kesimlerini dönüştürmektedir. Daha fazla bilgi için bkz. Sayfa yollarını özelleştirmek için parametre dönüştürücü kullanma.

URL oluşturma başvurusu

Bu bölüm, URL oluşturma tarafından uygulanan algoritma için bir başvuru içerir. Pratikte, URL oluşturmanın en karmaşık örnekleri denetleyiciler veya Razor Sayfalar kullanır. Ek bilgi için bkz. denetleyicilerde yönlendirme.

URL oluşturma işlemi LinkGenerator.GetPathByAddress veya benzer bir yöntem çağrısıyla başlar. yöntemine bir adres, bir yol değerleri kümesi ve isteğe bağlı olarak gelen geçerli istek hakkında bilgiler HttpContext sağlanır.

İlk adım, adresin türüyle eşleşen bir kullanarak bir dizi aday IEndpointAddressScheme<TAddress> uç noktayı çözümlemek için adresini kullanmaktır.

Aday kümesi adres düzeni tarafından bulunduktan sonra, url oluşturma işlemi başarılı olana kadar uç noktalar yinelenerek işlenir. URL oluşturma belirsizlikleri denetlemez, döndürülen ilk sonuç nihai sonuç olur.

Günlüğe kaydetme ile URL oluşturma sorunlarını giderme

URL oluşturma sorunlarını gidermenin ilk adımı günlüğe kaydetme düzeyini olarak Microsoft.AspNetCore.Routing TRACE ayarlamadır. LinkGenerator , işlemeyle ilgili birçok ayrıntıyı günlüğe kaydeder ve bu da sorunları gidermek için yararlı olabilir.

URL oluşturmayla ilgili ayrıntılar için bkz. URL oluşturma başvurusu.

Adresler

Adresler, bağlantı oluşturucuya bir çağrıyı bir dizi aday uç noktasına bağlamak için kullanılan URL oluşturma kavramıdır.

Adresler, varsayılan olarak iki uygulamayla birlikte gelen genişletilebilir bir kavramdır:

• Adres olarak uç nokta adını ( ) string kullanma:
  • MVC'nin yol adına benzer işlevler sağlar.
  • Meta veri IEndpointNameMetadata türünü kullanır.
  • Sağlanan dizeyi tüm kayıtlı uç noktaların meta verilerine göre çözümler.
  • Birden çok uç nokta aynı adı kullanıyorsa başlangıçta bir özel durum oluşturur.
  • Denetleyiciler ve Sayfalar dışında genel amaçlı kullanım için Razor önerilir.
• Adres olarak yol değerlerini ( ) RouteValuesAddress kullanma:
  • Denetleyicilere ve Sayfalar eski URL oluşturma Razor özelliğine benzer işlevler sağlar.
  • Genişletmek ve hata ayıklamak çok karmaşıktır.
  • , Etiket IUrlHelper Yardımcıları, HTML Yardımcıları, Eylem Sonuçları vb. tarafından kullanılan uygulamasını sağlar.

Adres düzeninin rolü, rastgele ölçütlere göre adres ve eşleşen uç noktalar arasındaki ilişkilendirmeyi yapmaktır:

• Uç nokta adı düzeni, temel bir sözlük araması gerçekleştirir.
• Yol değerleri şeması, ayarlanmış algoritmanın karmaşık bir en iyi alt kümesine sahiptir.

Ortam değerleri ve açık değerler

Geçerli istekten yönlendirme, geçerli isteğin yol değerlerine HttpContext.Request.RouteValues erişer. Geçerli istekle ilişkili değerler, ortam değerleri olarak adlandırılır. Belgeler, netlik sağlamak amacıyla yöntemlere geçirilen yol değerlerini açık değerler olarak ifade eder.

Aşağıdaki örnek, ortam değerlerini ve açık değerleri gösterir. Geçerli istekten ortam değerlerini ve açık değerleri { id = 17, } sağlar:

public class WidgetController : Controller
{
    private readonly LinkGenerator _linkGenerator;

    public WidgetController(LinkGenerator linkGenerator)
    {
        _linkGenerator = linkGenerator;
    }

    public IActionResult Index()
    {
        var url = _linkGenerator.GetPathByAction(HttpContext,
                                                 null, null,
                                                 new { id = 17, });
        return Content(url);
    }

Yukarıdaki kod:

• Döndürür /Widget/Index/17
• LinkGeneratorDI aracılığıyla alır.

Aşağıdaki kod hiçbir ortam değeri ve açık değer { controller = "Home", action = "Subscribe", id = 17, } sağlar:

public IActionResult Index2()
{
    var url = _linkGenerator.GetPathByAction("Subscribe", "Home",
                                             new { id = 17, });
    return Content(url);
}

Yukarıdaki yöntem döndürür /Home/Subscribe/17

içinde aşağıdaki kod WidgetController /Widget/Subscribe/17 döndürür:

var url = _linkGenerator.GetPathByAction("Subscribe", null,
                                         new { id = 17, });

Aşağıdaki kod, geçerli istekte yer alan ortam değerlerinden denetleyiciyi ve açık değerleri { action = "Edit", id = 17, } sağlar:

public class GadgetController : Controller
{
    public IActionResult Index()
    {
        var url = Url.Action("Edit", new { id = 17, });
        return Content(url);
    }

Yukarıdaki kodda:

• /Gadget/Edit/17 döndürülür.
• Url , IUrlHelper alır.
• Action
  , bir eylem yöntemi için mutlak yolu olan bir URL üretir. URL belirtilen adı ve action değerleri route içerir.

Aşağıdaki kod, geçerli istekten çevresel değerleri ve açık değerleri { page = "./Edit, id = 17, } sağlar:

public class IndexModel : PageModel
{
    public void OnGet()
    {
        var url = Url.Page("./Edit", new { id = 17, });
        ViewData["URL"] = url;
    }
}

Yukarıdaki kod, url /Edit/17 Sayfayı Düzenle aşağıdaki Razor sayfa yönergesi içerdiğinde olarak ayarlar:

@page "{id:int}"

Düzenle sayfasında yol şablonu "{id:int}" yoksa, url /Edit?id=17 olur.

MVC'nin IUrlHelper davranışı, burada açıklanan kurallara ek olarak bir karmaşıklık katmanı ekler:

• IUrlHelper her zaman geçerli istekten yol değerlerini ortam değerleri olarak sağlar.
• IUrlHelper.Action, geliştirici tarafından geçersiz kılınmadıkça geçerli ve rota değerlerini her action zaman açık değerler olarak controller kopyalar.
• IUrlHelper.Page geçersiz kılınmadıkça page geçerli yol değerini her zaman açık bir değer olarak kopyalar.
• IUrlHelper.Page geçersiz kılınmadıkça handler geçerli yol değerini her zaman açık değerler olarak geçersiz null kılar.

MVC kendi kurallarına uygun görünmey olduğundan, ortam değerlerinin davranış ayrıntıları genellikle kullanıcılar tarafından şaşırtılmıştır. Geçmiş ve uyumluluk nedenleriyle, , , ve gibi belirli yol action değerleri kendi özel durum controller page handler davranışlarına sahiptir.

ve tarafından sağlanan eşdeğer LinkGenerator.GetPathByAction LinkGenerator.GetPathByPage işlevsellik, uyumluluk için bu IUrlHelper anomalilerini yineler.

URL oluşturma işlemi

Aday uç nokta kümesi bulunduktan sonra URL oluşturma algoritması:

• Uç noktaları iterative olarak işleme.
• İlk başarılı sonucu döndürür.

Bu işlemde ilk adım yol değeri geçersiz kılınma olarak adlandırılan adımdır. Yol değeri geçersiz kılınma, yönlendirmenin ortam değerlerinden hangi yol değerlerinin kullanacağız ve yoksayılacak olduğuna karar verme işlemidir. Her ortam değeri dikkate alınır ve açık değerlerle bir araya gelir veya yoksayılır.

Ortam değerlerinin rolünü düşünmenin en iyi yolu, bazı yaygın durumlarda uygulama geliştiricilerinin yazmasını kaydetmeye çalışmalarıdır. Geleneksel olarak, ortam değerlerinin yararlı olduğu senaryolar MVC ile ilgilidir:

• Aynı denetleyicide başka bir eyleme bağlantı sağlarken denetleyici adının belirtilmemiş olması gerekir.
• Aynı alanda başka bir denetleyiciye bağlantı sağlarken alan adının belirtilmemiş olması gerekir.
• Aynı eylem yöntemine bağlanırken, rota değerlerinin belirtilmesi gerekmez.
• Uygulamanın başka bir bölümüne bağlanırken, uygulamanın o bölümünde anlamı olmayan rota değerlerini yürütmek istemezsiniz.

Ya da LinkGenerator IUrlHelper Bu dönüşe yapılan çağrılar null genellikle yol değeri doğrulaması anlaşılmadığında oluşur. Yolun sorunu çözüp çözmediğini görmek için daha fazla yol değeri belirtip yol değerlerini geçersiz kılma sorunlarını giderin.

Rota değeri geçersiz kılma, uygulamanın URL şeması, soldan sağa doğru oluşturulmuş bir hiyerarşi ile hiyerarşik olduğu varsayımıyla birlikte çalışıyor. {controller}/{action}/{id?}Bu uygulamada nasıl çalıştığını daha kolay bir şekilde öğrenmek için temel denetleyici yönlendirme şablonunu göz önünde bulundurun. Bir değer değişikliği , sağda görünen tüm rota değerlerini geçersiz kılar . Bu, hiyerarşiyle ilgili varsayımını yansıtır. Uygulamanın için bir ortam değeri varsa id ve işlem için farklı bir değer belirtiyorsa controller :

• id``{controller}, öğesinin solunda olduğu için yeniden kullanılamaz {id?} .

Bu ilkeyi gösteren bazı örnekler:

• Açık değerler için bir değer içeriyorsa id , ortam değeri id yok sayılır. Ve için çevresel değerler controller action kullanılabilir.
• Açık değerler için bir değer içeriyorsa action , için herhangi bir ortam değeri action yok sayılır. İçin çevresel değerler controller kullanılabilir. İçin açık değeri, action için çevresel değerden farklıysa action , id değer kullanılmaz. İçin açık değeri, action için çevresel değer ile aynıysa action , id değer kullanılabilir.
• Açık değerler için bir değer içeriyorsa controller , için herhangi bir ortam değeri controller yok sayılır. İçin açık değeri, controller için çevresel değerden farklıysa controller , action ve id değerleri kullanılmaz. İçin açık değeri, controller için çevresel değer ile aynıysa controller , action ve id değerleri kullanılabilir.

Bu işlem, öznitelik yollarının ve adanmış geleneksel yolların varlığı tarafından daha karmaşıktır. {controller}/{action}/{id?}Yönlendirme parametrelerini kullanarak bir hiyerarşiyi belirtmek gibi denetleyici geleneksel yolları. Özel geleneksel yollar ve denetleyicilere ve sayfalara yönelik öznitelik yolları için Razor :

• Yol değerlerinin bir hiyerarşisi vardır.
• Bunlar şablonda görünmez.

Bu gibi durumlarda, URL oluşturma gerekli değerler kavramını tanımlar. Denetleyiciler ve sayfalar tarafından oluşturulan uç noktalar, Razor Rota değeri geçersiz kılma çalışmasına izin veren gerekli değerlere sahiptir.

Ayrıntı olarak yol değeri geçersiz kılma algoritması:

• Gerekli değer adları, yol parametreleriyle birleştirilir ve soldan sağa işlenir.
• Her parametre için çevresel değer ve açık değer karşılaştırılır:
  • Çevresel değer ve açık değer aynıysa işlem devam eder.
  • Çevresel değer varsa ve açık değer değilse, URL oluşturulurken çevresel değer kullanılır.
  • Çevresel değer yoksa ve açık değer ise, ortam değerini ve sonraki tüm ortam değerlerini reddedin.
  • Çevresel değer ve açık değer varsa ve iki değer farklıysa, ortam değerini ve sonraki tüm ortam değerlerini reddedin.

Bu noktada, URL oluşturma işlemi yol kısıtlamalarını değerlendirmek için hazırlayın. Kabul edilen değerler kümesi, kısıtlamalara sunulan parametre varsayılan değerleriyle birleştirilir. Kısıtlamaların tümü başarılı olursa işlem devam eder.

Ardından, kabul edilen değerler yol şablonunu genişletmek için kullanılabilir. Yol şablonu işlenir:

• Soldan sağa.
• Her parametrenin kabul edilen değeri değiştirildi.
• Aşağıdaki özel durumlar ile:
  • Kabul edilen değerlerde bir değer eksikse ve parametrenin varsayılan değeri varsa, varsayılan değer kullanılır.
  • Kabul edilen değerlerde bir değer eksikse ve parametresi isteğe bağlıdır, işleme devam eder.
  • Eksik bir isteğe bağlı parametrenin sağında herhangi bir rota parametresinin değeri varsa, işlem başarısız olur.
  • Ardışık varsayılan değerli parametreler ve isteğe bağlı parametreler mümkün olduğunda daraltılır.

Yolun bir segmentiyle eşleşmeyen değerler sorgu dizesine eklenir. Aşağıdaki tabloda, yol şablonu kullanılırken sonuç gösterilmektedir {controller}/{action}/{id?} .

Rota değeri geçersiz kılma sorunları

ASP.NET Core 3,0 itibariyle, önceki ASP.NET Core sürümlerde kullanılan bazı url oluşturma şemaları, url oluşturma ile iyi çalışmaz. ASP.NET Core takım, gelecekteki sürümlerde bu ihtiyaçları karşılamak için özellik eklemeyi planlıyor. Şimdilik en iyi çözüm eski yönlendirmeyi kullanmaktır.

Aşağıdaki kod, yönlendirme tarafından desteklenmeyen bir URL oluşturma şemasına bir örnek gösterir.

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute("default", 
                                     "{culture}/{controller=Home}/{action=Index}/{id?}");
    endpoints.MapControllerRoute("blog", "{culture}/{**slug}", 
                                      new { controller = "Blog", action = "ReadPost", });
});

Yukarıdaki kodda, culture Yerelleştirme için Route parametresi kullanılır. Bunun için culture parametre her zaman bir çevresel değer olarak kabul edilir. Ancak, culture gerekli değerlerin çalışma şekli nedeniyle parametre bir çevresel değer olarak kabul edilmez:

• "default"Yol şablonunda, culture yol parametresi solunda bulunur controller , bu nedenle değişiklikler controller geçersiz olmaz culture .
• "blog"Yol şablonunda, culture yol parametresi, controller gerekli değerlerde görüntülenen, öğesinin sağında kabul edilir.

Uç nokta meta verilerini yapılandırma

Aşağıdaki bağlantılar, uç nokta meta verilerini yapılandırma hakkında bilgi sağlar:

• Uç nokta yönlendirme ile CORS 'yi etkinleştirme
• Özel bir öznitelik kullanan ıauthorizationpolicyprovider örneği [MinimumAgeAuthorize]
• [Yetkilendir] özniteliğiyle test kimlik doğrulaması
• RequireAuthorization
• [Yetkilendir] özniteliğiyle düzeni seçme
• [Yetkilendir] özniteliğini kullanarak ilke uygulama
• ASP.NET Core'de rol tabanlı yetkilendirme

RequireHost ile yollarla eşleşen ana bilgisayar

RequireHost rotaya belirtilen Konağı gerektiren bir kısıtlama uygular. RequireHostVeya [Host] parametresi şu olabilir:

• Ana bilgisayar: www.domain.com , www.domain.com herhangi bir bağlantı noktasıyla eşleşir.
• Joker karakterle,, *.domain.com www.domain.com subdomain.domain.com veya www.subdomain.domain.com herhangi bir bağlantı noktasında eşleşen ana bilgisayar.
• Bağlantı noktası: *:5000 , bağlantı noktası 5000 ile herhangi bir konak ile eşleşir.
• Konak ve bağlantı noktası: www.domain.com:5000 veya *.domain.com:5000 , ana bilgisayar ve bağlantı noktasıyla eşleşir.

Veya kullanılarak birden çok parametre belirtilebilir RequireHost [Host] . Kısıtlama, parametrelerden herhangi biri için geçerli olan konaklarla eşleşir. Örneğin,, [Host("domain.com", "*.domain.com")] ve ile eşleşir domain.com www.domain.com subdomain.domain.com .

Aşağıdaki kod, RequireHost rotada belirtilen Konağı gerektirmek için kullanır:

public void Configure(IApplicationBuilder app)
{
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", context => context.Response.WriteAsync("Hi Contoso!"))
            .RequireHost("contoso.com");
        endpoints.MapGet("/", context => context.Response.WriteAsync("AdventureWorks!"))
            .RequireHost("adventure-works.com");
        endpoints.MapHealthChecks("/healthz").RequireHost("*:8080");
    });
}

Aşağıdaki kod, [Host] belirtilen konaklardan herhangi birini gerektirmek için denetleyicideki özniteliğini kullanır:

[Host("contoso.com", "adventure-works.com")]
public class ProductController : Controller
{
    public IActionResult Index()
    {
        return ControllerContext.MyDisplayRouteInfo();
    }

    [Host("example.com:8080")]
    public IActionResult Privacy()
    {
        return ControllerContext.MyDisplayRouteInfo();
    }
}

[Host]Özniteliği hem denetleyici hem de eylem yöntemine uygulandığında:

• Eylem üzerindeki özniteliği kullanılır.
• Denetleyici özniteliği yok sayılır.

Yönlendirme için performans Kılavuzu

yönlendirmenin çoğu, performansı artırmak için ASP.NET Core 3,0 ' de güncelleştirildi.

Bir uygulamada performans sorunları olduğunda, yönlendirme genellikle sorun olarak şüpheli. Yönlendirme nedeni, denetleyiciler ve sayfalar gibi çerçevelerin, Razor kendi günlük iletilerinde çerçeve içinde harcanan süreyi raporlamadır. Denetleyiciler tarafından bildirilen zaman ve isteğin toplam süresi arasında önemli bir fark olduğunda:

• Geliştiriciler, uygulamanın kodunu sorunun kaynağı olarak ortadan kaldırır.
• Yönlendirmenin neden olduğunu varsaymak yaygındır.

Yönlendirme, binlerce uç nokta kullanılarak performansa göre test edilir. Tipik bir uygulamanın çok büyük bir performans sorunuyla karşılaşmasının pek olası olması normaldir. Yavaş yönlendirme performansının en yaygın kök nedeni genellikle kötü performansa neden olan özel bir ara yazılımdır.

Aşağıdaki kod örneği, gecikme kaynağını daraltmak için temel bir tekniği gösteriyor:

public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
{
    app.Use(next => async context =>
    {
        var sw = Stopwatch.StartNew();
        await next(context);
        sw.Stop();

        logger.LogInformation("Time 1: {ElapsedMilliseconds}ms", sw.ElapsedMilliseconds);
    });

    app.UseRouting();

    app.Use(next => async context =>
    {
        var sw = Stopwatch.StartNew();
        await next(context);
        sw.Stop();

        logger.LogInformation("Time 2: {ElapsedMilliseconds}ms", sw.ElapsedMilliseconds);
    });

    app.UseAuthorization();

    app.Use(next => async context =>
    {
        var sw = Stopwatch.StartNew();
        await next(context);
        sw.Stop();

        logger.LogInformation("Time 3: {ElapsedMilliseconds}ms", sw.ElapsedMilliseconds);
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Timing test.");
        });
    });
}

Zaman yönlendirme:

• Her ara yazılımı önceki kodda gösterilen zamanlama ara yazılımı kopyasıyla birlikte kopyalayın.
• Zamanlama verileriyle kod arasında ilişki için benzersiz bir tanımlayıcı ekleyin.

Bu, önemli olduğunda gecikmeyi daraltmanın temel bir yolu, örneğin, 'den 10ms fazladır. Time 2Raporlardan, ara yazılım içinde harcanan zamanı Time 1 UseRouting çıkarma.

Aşağıdaki kod, önceki zamanlama koduna daha küçük bir yaklaşım kullanır:

public sealed class MyStopwatch : IDisposable
{
    ILogger<Startup> _logger;
    string _message;
    Stopwatch _sw;

    public MyStopwatch(ILogger<Startup> logger, string message)
    {
        _logger = logger;
        _message = message;
        _sw = Stopwatch.StartNew();
    }

    private bool disposed = false;


    public void Dispose()
    {
        if (!disposed)
        {
            _logger.LogInformation("{Message }: {ElapsedMilliseconds}ms",
                                    _message, _sw.ElapsedMilliseconds);

            disposed = true;
        }
    }
}

public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
{
    int count = 0;
    app.Use(next => async context =>
    {
        using (new MyStopwatch(logger, $"Time {++count}"))
        {
            await next(context);
        }

    });

    app.UseRouting();

    app.Use(next => async context =>
    {
        using (new MyStopwatch(logger, $"Time {++count}"))
        {
            await next(context);
        }
    });

    app.UseAuthorization();

    app.Use(next => async context =>
    {
        using (new MyStopwatch(logger, $"Time {++count}"))
        {
            await next(context);
        }
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Timing test.");
        });
    });
}

Pahalı olabilecek yönlendirme özellikleri

Aşağıdaki liste, temel yol şablonlarıyla karşılaştırıldığında görece pahalı olan yönlendirme özellikleri hakkında bazı içgörüler sağlar:

• Normal ifadeler: Karmaşık veya az miktarda girişle uzun süre çalışan normal ifadeler yazmak mümkündür.

• Karmaşık segmentler ( {x}-{y}-{z} ):

  • Normal bir URL yolu kesimini ayrıştırmaktan çok daha pahalıdır.
  • Çok daha fazla alt dizenin ayrılırken sonuç.
  • Karmaşık segment mantığı, 3.0 ASP.NET Core güncelleştirmesi ile güncelleştirilmedi.

• Zaman uyumlu veri erişimi: Birçok karmaşık uygulama, yönlendirmelerinin bir parçası olarak veritabanı erişimine sahip olur. ASP.NET Core 2.2 ve önceki yönlendirmeler veritabanı erişim yönlendirmeyi desteklemek için doğru genişletilebilirlik noktalarını sağlamayabilirsiniz. Örneğin, IRouteConstraint ve IActionConstraint zaman uyumlu olur. ve gibi genişletilebilirlik MatcherPolicy EndpointSelectorContext noktaları zaman uyumsuz.

Büyük rota tabloları için kılavuz

Varsayılan olarak ASP.NET Core CPU süresiyle takas olan bir yönlendirme algoritması kullanır. Bu, yol eşleştirme süresinin, yol sayısına değil, yalnızca eşleştirilen yolun uzunluğuna bağlı olduğu iyi bir etkiye sahiptir. Ancak, uygulamanın çok sayıda yolu (binlerce) olduğunda ve yollarda yüksek miktarda değişken ön eki olduğunda bu yaklaşım bazı durumlarda sorunlu olabilir. Örneğin, yolların yolunun erken segmentlerinde parametreleri varsa, {parameter}/some/literal örneğin.

Bir uygulamanın, şu durumlar için sorun olduğu bir durumla karşı karşılasma ihtimali düşük olabilir:

• Bu düzeni kullanan uygulamada çok sayıda yol vardır.
• Uygulamada çok sayıda yol vardır.

Bir uygulamanın büyük yönlendirme tablosu sorunuyla karşıtlı olup olmadığını belirleme

• Bakacak iki ortak ifade vardır:
  • Uygulamanın ilk istekte yavaş başlaması.
    • Bunun gerekli olduğunu ancak yeterli olmadığını unutmayın. Yavaş uygulama başlatmaya neden olandan çok daha fazla yol dışı sorun vardır. Uygulamanın bu durumda olduğunu doğru şekilde belirlemek için aşağıdaki koşulu kontrol edin.
  • Uygulama başlatma sırasında çok fazla bellek tüketir ve bellek dökümü çok sayıda Microsoft.AspNetCore.Routing.Matching.DfaNode örneği gösterir.

Bu sorunu ele ala

Bu senaryoyu büyük ölçüde geliştirecek yollar için çeşitli teknikler ve iyileştirmeler kullanılabilir:

• Mümkün olduğunca parametrelerinize yol kısıtlamaları {parameter:int} {parameter:guid} (örneğin, , , {parameter:regex(\\d+)} vb.) uygulama.
  • Bu, yönlendirme algoritmasının eşleştirme için kullanılan yapıları dahili olarak iyileştirmesi ve kullanılan belleği önemli ölçüde azaltmasını sağlar.
  • Çoğu durumda bu, kabul edilebilir bir davranışa geri dönmek için yeterli olacaktır.
• Parametreleri şablonda sonraki segmentlere taşımak için yolları değiştirme.
  • Bu, bir yol verilen uç noktayla eşleşmesi için olası "yolların" sayısını azaltır.
• Dinamik bir yol kullanın ve denetleyiciye/sayfaya eşlemeyi dinamik olarak gerçekleştirin.
  • Bu, ve kullanılarak MapDynamicControllerRoute elde MapDynamicPageRoute edilebilir.

Kitaplık yazarları için rehberlik

Bu bölüm, yönlendirmenin üzerine inşaa olan kitaplık yazarlarının kılavuzlarını içerir. Bu ayrıntılar, uygulama geliştiricilerinin yönlendirmeyi genişleten kitaplıkları ve çerçeveleri kullanarak iyi bir deneyim yaşamalarını sağlamak için tasarlanmıştır.

Uç noktaları tanımlama

URL eşleştirmesi için yönlendirme kullanan bir çerçeve oluşturmak için, üzerine ek olarak bir kullanıcı deneyimi tanımlayarak UseEndpoints başlayalım.

üzerinde DO IEndpointRouteBuilder derlemesi. Bu, kullanıcıların çerçevenizi karışıklık olmadan diğer ASP.NET Core oluşturmalarını sağlar. Her ASP.NET Core şablonu yönlendirmeyi içerir. Yönlendirmenin kullanıcılar için mevcut ve tanıdık olduğunu varsayalım.

app.UseEndpoints(endpoints =>
{
    // Your framework
    endpoints.MapMyFramework(...);

    endpoints.MapHealthChecks("/healthz");
});

DO, uygulayan çağrısından korumalı bir MapMyFramework(...) somut tür iade IEndpointConventionBuilder ediyor. Çoğu çerçeve Map... yöntemi bu düzeni kullanır. IEndpointConventionBuilderArabirim:

• Meta verilerin birliğini sağlar.
• Çeşitli uzantı yöntemleri tarafından hedeflidir.

Kendi türlerinizi bildirerek oluşturucuya çerçeveye özgü kendi işlevselliğinizi eklemenize olanak sağlar. Çerçeve tarafından bildirilen bir oluşturucu sarmalar ve buna çağrılar iletir.

app.UseEndpoints(endpoints =>
{
    // Your framework
    endpoints.MapMyFramework(...).RequireAuthorization()
                                 .WithMyFrameworkFeature(awesome: true);

    endpoints.MapHealthChecks("/healthz");
});

Kendi yazmanızı EndpointDataSource DÜŞÜNÜN. EndpointDataSource , uç nokta koleksiyonunu bildirime ve güncelleştirmeye uygun alt düzey temel öğedir. EndpointDataSource , denetleyiciler ve Sayfalar tarafından kullanılan güçlü bir Razor API'dir.

Yönlendirme testlerinde, güncelleştirilen bir veri kaynağının temel bir örneği yer alan.

Varsayılan olarak kaydetmeyi EndpointDataSource DENEMEYİN. Kullanıcıların çerçevenizi 'a kaydetmesini UseEndpoints gerektir. Yönlendirme anlayışı, varsayılan olarak hiçbir şeyin dahil olmadığını ve uç UseEndpoints noktaların kaydedilene yer olduğudur.

Yönlendirmeyle tümleşik ara yazılım oluşturma

Meta veri türlerini arabirim olarak tanımlamayı DÜŞÜNÜN.

YAPIN: Sınıflarda ve yöntemlerde meta veri türlerini öznitelik olarak kullanabilirsiniz.

public interface ICoolMetadata
{
    bool IsCool { get; }
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class CoolMetadataAttribute : Attribute, ICoolMetadata
{
    public bool IsCool => true;
}

Denetleyiciler ve Sayfalar gibi Razor çerçeveler, türlere ve yöntemlere meta veri özniteliklerini uygulamayı destekler. Meta veri türlerini bildirersiniz:

• Bunları öznitelik olarak erişilebilir hale.
• Kullanıcıların çoğu öznitelikleri uygulama hakkında bilgi sahibidir.

Bir meta veri türünü arabirim olarak bildirim başka bir esneklik katmanı daha ekler:

• Arabirimler birleştirilebilir.
• Geliştiriciler, birden çok ilkeyi birleştiren kendi türlerini bildirer.

YAPIN: Aşağıdaki örnekte gösterildiği gibi meta verileri geçersiz kılmayı mümkün kılın:

public interface ICoolMetadata
{
    bool IsCool { get; }
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class CoolMetadataAttribute : Attribute, ICoolMetadata
{
    public bool IsCool => true;
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class SuppressCoolMetadataAttribute : Attribute, ICoolMetadata
{
    public bool IsCool => false;
}

[CoolMetadata]
public class MyController : Controller
{
    public void MyCool() { }

    [SuppressCoolMetadata]
    public void Uncool() { }
}

Bu yönergeleri izlemenin en iyi yolu, işaretçi meta verilerini tanımlamaktan kaçınmaktır:

• Yalnızca meta veri türünün varlığını aramayın.
• Meta verilerde bir özellik tanımlayın ve özelliğini kontrol edin.

Meta veri koleksiyonu sıralıdır ve önceliğe göre geçersiz kılmayı destekler. Denetleyiciler durumunda, eylem yönteminde meta veriler en özeldir.

DO, yönlendirme ile ve yönlendirme olmadan ara yazılımı yararlı hale sağlar.

app.UseRouting();

app.UseAuthorization(new AuthorizationPolicy() { ... });

app.UseEndpoints(endpoints =>
{
    // Your framework
    endpoints.MapMyFramework(...).RequireAuthorization();
});

Bu kılavuza örnek olarak ara yazılımı UseAuthorization göz önünde bulundurabilirsiniz. Yetkilendirme ara yazılımı bir geri dönüş ilkesi geçmeyi sağlar. Belirtilmişse geri dönüş ilkesi her ikisi için de geçerlidir:

• Belirtilen ilke olmayan uç noktalar.
• Uç noktayla eşleşmez istekler.

Bu, yetkilendirme ara yazılımlarını yönlendirme bağlamı dışında kullanışlı yapar. Yetkilendirme ara yazılımı, geleneksel ara yazılım programlaması için kullanılabilir.

Hata ayıklama tanılaması

Ayrıntılı yönlendirme tanılama çıktısı için, Logging:LogLevel:Microsoft olarak ayarlayın Debug . Geliştirme ortamında, appsettings.Development.jsüzerindeki günlük düzeyini ayarlayın:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Debug",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

Yönlendirme, gelen HTTP isteklerini eşleştirmeden ve bu istekleri uygulamanın yürütülebilir uç noktalarına göndermeden sorumludur. Uç noktalar, uygulamanın yürütülebilir istek işleme kodu birimleridir. Uç noktalar uygulamada tanımlanır ve uygulama başlatıldığında yapılandırılır. Uç nokta eşleştirme işlemi, isteğin URL'lerinden değerleri ayıklar ve istek işleme için bu değerleri sağlar. Yönlendirme, uygulamanın uç nokta bilgilerini kullanarak uç noktalara eşlene URL'ler de oluşturabilecektir.

Uygulamalar şunları kullanarak yönlendirmeyi yapılandırabilirsiniz:

• Denetleyiciler
• Razor Sayfa
• SignalR
• gRPC Services
• Sistem Durumu Denetimleri gibi uç nokta özellikli ara yazılım.
• Yönlendirme ile kayıtlı temsilciler ve Lambdalar.

bu belgede ASP.NET Core yönlendirmenin alt düzey ayrıntıları ele alınmaktadır. Yönlendirmeyi yapılandırma hakkında bilgi için:

• Denetleyiciler için bkz ASP.NET Core denetleyici eylemlerine yönlendirme ..
• RazorSayfa kuralları için bkz RazorSayfalarda yönlendirme ve uygulama kuralları ASP.NET Core ..

bu belgede açıklanan uç nokta yönlendirme sistemi, ASP.NET Core 3,0 ve üzeri için geçerlidir. önceki yönlendirme sistemiyle ilgili daha fazla bilgi için IRouter , aşağıdaki yaklaşımlardan birini kullanarak ASP.NET Core 2,1 sürümünü seçin:

• Önceki sürümün sürüm Seçicisi.
• ASP.NET Core 2,1 yönlendirmeöğesini seçin.

Örnek kodu görüntüleme veya indirme (nasıl indirileceği)

Bu belgenin karşıdan yükleme örnekleri belirli bir sınıf tarafından etkinleştirilir Startup . Belirli bir örneği çalıştırmak için program. cs ' yi istenen sınıfı çağırmak üzere değiştirin Startup .

Yönlendirme temelleri

tüm ASP.NET Core şablonları oluşturulan koda yönlendirmeyi içerir. Yönlendirme, içindeki Ara yazılım ardışık düzenine kaydedilir Startup.Configure .

Aşağıdaki kod, yönlendirmenin temel bir örneğini göstermektedir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Yönlendirme, ve tarafından kaydedilen bir dizi ara yazılımı UseRouting kullanır UseEndpoints :

• UseRouting ara yazılım ardışık düzenine eşleşen rota ekler. Bu ara yazılım, uygulamada tanımlanan uç nokta kümesine bakar ve isteğe bağlı olarak en iyi eşleşmeyi seçer.
• UseEndpoints uç nokta yürütmeyi ara yazılım ardışık düzenine ekler. Seçili uç noktayla ilişkili temsilciyi çalıştırır.

Önceki örnekte, Mapget yöntemi kullanılarak kod uç noktasına tek bir yol dahildir:

• GETKök URL 'ye BIR http isteği gönderildiğinde / :
  • Gösterilen istek temsilcisi yürütülüyor.
  • Hello World! HTTP yanıtına yazılır. Varsayılan olarak, kök URL 'sidir / https://localhost:5001/ .
• İstek yöntemi yoksa GET veya kök URL 'si değilse / , hiçbir yol eşleşmesi ve bir HTTP 404 döndürülür.

Uç Nokta

MapGetYöntemi, bir uç noktayı tanımlamak için kullanılır. Uç nokta şöyle olabilir:

• URL ve HTTP yöntemiyle eşleştirerek seçilir.
• , Temsilcisi çalıştırılarak yürütülür.

Uygulama tarafından eşleştirilecek ve çalıştırılabilen uç noktalar ' de yapılandırılır UseEndpoints . Örneğin,, MapGet MapPost ve benzer yöntemler , istek temsilcilerinizi yönlendirme sistemine bağlanır. ASP.NET Core framework özelliklerini yönlendirme sistemine bağlamak için ek yöntemler kullanılabilir:

• Sayfalar Razor için harita sayfaları Razor
• Denetleyiciler için MapControllers
• MapHub <THub>SignalR
• GRPC için MapGrpcService <TService>

Aşağıdaki örnekte, daha karmaşık bir yol şablonuyla yönlendirme gösterilmektedir:

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("/hello/{name:alpha}", async context =>
    {
        var name = context.Request.RouteValues["name"];
        await context.Response.WriteAsync($"Hello {name}!");
    });
});

Dize /hello/{name:alpha} bir yol şablonudur. Uç noktanın nasıl eşleştirileceği yapılandırmak için kullanılır. Bu durumda, şablon eşleşir:

• Şunun gibi bir URL /hello/Ryan
• /hello/Arkasından bir alfabetik karakter dizisi ile başlayan herhangi BIR URL yolu. :alpha yalnızca alfabetik karakterlerle eşleşen bir rota kısıtlaması uygular. Yol kısıtlamaları bu belgenin ilerleyen kısımlarında açıklanmıştır.

URL yolunun ikinci segmenti {name:alpha} :

• nameParametreye bağlanır.
• Yakalanır ve HttpRequest. RouteValues'da depolanır.

bu belgede açıklanan uç nokta yönlendirme sistemi ASP.NET Core 3,0 itibariyle yenidir. ancak, ASP.NET Core tüm sürümleri aynı yol şablonu özellikleri ve yol kısıtlamaları kümesini destekler.

Aşağıdaki örnek, durum denetimleri ve yetkilendirmeyle yönlendirmeyi gösterir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    // Matches request to an endpoint.
    app.UseRouting();

    // Endpoint aware middleware. 
    // Middleware can use metadata from the matched endpoint.
    app.UseAuthentication();
    app.UseAuthorization();

    // Execute the matched endpoint.
    app.UseEndpoints(endpoints =>
    {
        // Configure the Health Check endpoint and require an authorized user.
        endpoints.MapHealthChecks("/healthz").RequireAuthorization();

        // Configure another endpoint, no authorization requirements.
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Ingilizce dışındaki dillere çevrilmiş kod açıklamalarını görmek isterseniz, Bu GitHub tartışma sorununubize tanıyın.

Yukarıdaki örnekte nasıl yapılacağı gösterilmektedir:

• Yetkilendirme ara yazılımı yönlendirmeyle birlikte kullanılabilir.
• Uç noktalar, yetkilendirme davranışını yapılandırmak için kullanılabilir.

MapHealthChecksÇağrı bir sistem durumu denetim uç noktası ekler. RequireAuthorizationBu çağrıda zincir, bir yetkilendirme ilkesini uç noktaya iliştirir.

UseAuthentication UseAuthorization Kimlik doğrulama ve yetkilendirme ara yazılımını çağırarak ve ekler. Bu ara yazılım, ile arasında yerleştirilir UseRouting ve UseEndpoints şunları yapabilir:

• Hangi uç noktanın seçili olduğunu görün UseRouting .
• Uç noktaya göndermeden önce bir yetkilendirme ilkesi uygulayın UseEndpoints .

Uç nokta meta verileri

Yukarıdaki örnekte, iki uç nokta bulunur, ancak yalnızca sistem durumu denetimi uç noktasına bağlı bir yetkilendirme ilkesi vardır. İstek sistem durumu denetimi uç noktasıyla eşleşiyorsa, /healthz bir yetkilendirme denetimi gerçekleştirilir. Bu, uç noktalara eklenen ek verilere sahip olduğunu gösterir. Bu ek verilere uç nokta meta verileri denir:

• Meta veriler, yönlendirme kullanan ara yazılım tarafından işlenebilir.
• Meta veriler herhangi bir .NET türü olabilir.

Yönlendirme kavramları

Yönlendirme sistemi güçlü uç nokta kavramı ekleyerek, ara yazılım ardışık düzeninin üst kısmında oluşturulur. uç noktalar, yönlendirme, yetkilendirme ve herhangi bir sayıda ASP.NET Core sistemi açısından birbirinden farklı olan uygulama işlevselliğinin birimlerini temsil eder.

ASP.NET Core uç noktası tanımı

ASP.NET Core uç noktası:

• Yürütülebilir dosya: öğesine sahip RequestDelegate .
• Genişletilebilir: meta veri koleksiyonu vardır.
• Seçilebilir: Isteğe bağlı olarak yönlendirme bilgilerivardır.
• Numaralandırılabilir: bitiş noktaları koleksiyonu, kimden kaynağından alma yoluyla listelenebilir EndpointDataSource .

Aşağıdaki kod, geçerli istekle eşleşen uç noktanın nasıl alınacağını ve inceleneceği gösterilmektedir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();

    app.Use(next => context =>
    {
        var endpoint = context.GetEndpoint();
        if (endpoint is null)
        {
            return Task.CompletedTask;
        }
        
        Console.WriteLine($"Endpoint: {endpoint.DisplayName}");

        if (endpoint is RouteEndpoint routeEndpoint)
        {
            Console.WriteLine("Endpoint has route pattern: " +
                routeEndpoint.RoutePattern.RawText);
        }

        foreach (var metadata in endpoint.Metadata)
        {
            Console.WriteLine($"Endpoint has metadata: {metadata}");
        }

        return Task.CompletedTask;
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Seçildiğinde, uç nokta öğesinden alınabilir HttpContext . Özellikleri incelenebilir. Uç nokta nesneleri sabittir ve oluşturulduktan sonra değiştirilemez. Uç noktanın en yaygın türü bir RouteEndpoint . RouteEndpoint , yönlendirme sistemi tarafından seçilebilir olan bilgileri içerir.

Yukarıdaki kod, uygulama. Kullanım , çevrimiçi bir Ara yazılımyapılandırır.

Aşağıdaki kod, işlem hattında nereye app.Use çağrdığına bağlı olarak bir uç nokta olmayabilir:

// Location 1: before routing runs, endpoint is always null here
app.Use(next => context =>
{
    Console.WriteLine($"1. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
    return next(context);
});

app.UseRouting();

// Location 2: after routing runs, endpoint will be non-null if routing found a match
app.Use(next => context =>
{
    Console.WriteLine($"2. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
    return next(context);
});

app.UseEndpoints(endpoints =>
{
    // Location 3: runs when this endpoint matches
    endpoints.MapGet("/", context =>
    {
        Console.WriteLine(
            $"3. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
        return Task.CompletedTask;
    }).WithDisplayName("Hello");
});

// Location 4: runs after UseEndpoints - will only run if there was no match
app.Use(next => context =>
{
    Console.WriteLine($"4. Endpoint: {context.GetEndpoint()?.DisplayName ?? "(null)"}");
    return next(context);
});

Bu önceki örnek Console.WriteLine , bir uç noktanın seçili olup olmadığını gösteren deyimler ekliyor. Netlik açısından örnek, belirtilen uç noktaya bir görünen ad atar / .

Bu kodu, ekran URL 'SI ile çalıştırma / :

1. Endpoint: (null)
2. Endpoint: Hello
3. Endpoint: Hello

Bu kodu başka bir URL ile çalıştırmak şunları görüntüler:

1. Endpoint: (null)
2. Endpoint: (null)
4. Endpoint: (null)

Bu çıkış şunları gösterir:

• Bitiş noktası, çağrılmadan önce her zaman null olur UseRouting .
• Bir eşleşme bulunursa, uç nokta ve arasında boş değildir UseRouting UseEndpoints .
• UseEndpointsBir eşleşme bulunduğunda ara yazılım terminaldir . Terminal ara yazılımı bu belgede daha sonra tanımlanır.
• UseEndpointsYalnızca eşleşme bulunamadığında yürütme sonrasında ara yazılım.

UseRoutingAra yazılım, uç noktayı geçerli bağlama eklemek Için setendpoint yöntemini kullanır. UseRoutingAra yazılımı özel mantık ile değiştirmek ve uç noktaları kullanmanın avantajlarını almaya devam etmek mümkündür. Uç noktalar, ara yazılım gibi alt düzey bir temel 'tür ve yönlendirme uygulamasıyla birlikte aktarılmaz. Çoğu uygulamanın UseRouting özel mantık ile değiştirme gereksinimi yoktur.

Ara UseEndpoints yazılım, ara yazılımla birlikte kullanılacak UseRouting şekilde tasarlanmıştır. Uç noktayı yürütmenin temel mantığı karmaşık değildir. uç GetEndpoint noktasını almak ve ardından özelliğini çağırmak için RequestDelegate kullanın.

Aşağıdaki kodda ara yazılımların yönlendirmeyi nasıl etkileyebilirsiniz veya buna nasıl tepki gösterebilirsiniz?

public class IntegratedMiddlewareStartup
{ 
    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        // Location 1: Before routing runs. Can influence request before routing runs.
        app.UseHttpMethodOverride();

        app.UseRouting();

        // Location 2: After routing runs. Middleware can match based on metadata.
        app.Use(next => context =>
        {
            var endpoint = context.GetEndpoint();
            if (endpoint?.Metadata.GetMetadata<AuditPolicyAttribute>()?.NeedsAudit
                                                                            == true)
            {
                Console.WriteLine($"ACCESS TO SENSITIVE DATA AT: {DateTime.UtcNow}");
            }

            return next(context);
        });

        app.UseEndpoints(endpoints =>
        {         
            endpoints.MapGet("/", async context =>
            {
                await context.Response.WriteAsync("Hello world!");
            });

            // Using metadata to configure the audit policy.
            endpoints.MapGet("/sensitive", async context =>
            {
                await context.Response.WriteAsync("sensitive data");
            })
            .WithMetadata(new AuditPolicyAttribute(needsAudit: true));
        });

    } 
}

public class AuditPolicyAttribute : Attribute
{
    public AuditPolicyAttribute(bool needsAudit)
    {
        NeedsAudit = needsAudit;
    }

    public bool NeedsAudit { get; }
}

Yukarıdaki örnekte iki önemli kavram gösterildi:

• Yönlendirmenin üzerinde çalışması UseRouting gereken verileri değiştirmek için ara yazılım daha önce çalışır.
  • Genellikle yönlendirmeden önce görüntülenen ara yazılım, isteğin , veya gibi bazı UseRewriter özelliğini değiştiren bir ara UseHttpMethodOverride UsePathBase yazılımdır.
• Ara yazılım, uç nokta UseRouting UseEndpoints yürütülmeden önce yönlendirme sonuçlarının iş için ve arasında çalışmasına olanak sağlar.
  • ile arasında çalışan ara UseRouting UseEndpoints yazılım:
    • Genellikle uç noktaları anlamak için meta verileri inceler.
    • genellikle ve tarafından yapılan güvenlik kararları UseAuthorization UseCors verir.
  • Ara yazılım ve meta verilerin birleşimi, uç nokta başına ilkelerin yapılandırılmasını sağlar.

Yukarıdaki kod, uç nokta başına ilkeleri destekleyen bir özel ara yazılım örneği gösterir. Ara yazılım, hassas verilere erişim denetim günlüğünü konsola yazar. Ara yazılım, meta verilerle bir uç noktayı denetlemeye AuditPolicyAttribute yalıtıldığında. Bu örnekte, yalnızca hassas olarak işaretlenen uç noktaların denetlenen bir kabul düzeni gösterildi. Bu mantığı ters yönde tanımlamak, örneğin güvenli olarak işaretlenen her şeyi denetlemek mümkündür. Uç nokta meta veri sistemi esnektir. Bu mantık, kullanım durumuna uygun herhangi bir şekilde tasar olabilir.

Yukarıdaki örnek kod, uç noktaların temel kavramlarını göstermek için tasarlanmıştır. Örnek, üretim kullanımına yönelik değildir. Denetim günlüğü ara yazılımlarının daha eksiksiz bir sürümü şu şekilde olabilir:

• Bir dosya veya veritabanında oturum açın.
• Kullanıcı, IP adresi, hassas uç noktanın adı ve daha fazlası gibi ayrıntıları dahil edin.

Denetim ilkesi meta AuditPolicyAttribute verileri, denetleyiciler Attribute ve gibi sınıf tabanlı çerçevelerle daha kolay kullanım için olarak SignalR tanımlanır. Kod yolu kullanırken:

• Meta veriler bir oluşturucu API'si ile ekli.
• Sınıf tabanlı çerçeveler, uç noktaları oluştururken ilgili yöntem ve sınıftaki tüm öznitelikleri içerir.

Meta veri türleri için en iyi yöntemler, bunları arabirim veya öznitelik olarak tanımlamaktır. Arabirimler ve öznitelikler kodun yeniden kullanılmasına olanak sağlar. Meta veri sistemi esnektir ve herhangi bir sınırlama uygulamaz.

Terminal ara yazılımlarını ve yönlendirmeyi karşılaştırma

Aşağıdaki kod örneği, yönlendirme kullanarak ara yazılım kullanmayı karşıtlık eder:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    // Approach 1: Writing a terminal middleware.
    app.Use(next => async context =>
    {
        if (context.Request.Path == "/")
        {
            await context.Response.WriteAsync("Hello terminal middleware!");
            return;
        }

        await next(context);
    });

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        // Approach 2: Using routing.
        endpoints.MapGet("/Movie", async context =>
        {
            await context.Response.WriteAsync("Hello routing!");
        });
    });
}

ile gösterilen ara yazılım stili Approach 1: terminal ara yazılımıdır. Bu, eşleşen bir işlem yaptığı için terminal ara yazılımı olarak adlandırılan bir işlemdir:

• Önceki örnekteki eşleştirme işlemi ara Path == "/" yazılım ve yönlendirme için Path == "/Movie" kullanılır.
• Bir eşleşme başarılı olduğunda, ara yazılımı değil, bazı işlevleri yürütür ve next döndürür.

Arama sonlandıran, bazı işlevleri yürüten ve sonra döndüren terminal ara yazılımı olarak adlandırılan bu ara yazılım.

Terminal ara yazılımı ile yönlendirmeyi karşılaştırma:

• Her iki yaklaşım da işlem hattını sonlandırmaya olanak sağlar:
  • Ara yazılım, 'i faturalamak yerine döndürerek işlem hattını next sonlandırılır.
  • Uç noktalar her zaman terminaldir.
• Terminal ara yazılımı, ara yazılımı işlem hattında rastgele bir konuma konumlandırmaya olanak sağlar:
  • Uç noktalar konumunda UseEndpoints yürütülür.
• Terminal ara yazılımı, rastgele kodun ara yazılımla ne zaman eş eşleşmesi olduğunu belirlemeye olanak sağlar:
  • Özel yol eşleştirme kodu ayrıntılı olabilir ve doğru yazabilir.
  • Yönlendirme, tipik uygulamalar için basit çözümler sağlar. Çoğu uygulama için özel yol eşleştirme kodu gerekli değil.
• ve gibi ara yazılım ile uç noktalar UseAuthorization UseCors arabirimi.
  • ile terminal ara yazılımı kullanmak UseAuthorization veya UseCors yetkilendirme sistemiyle el ile ara yazılım gerektirir.

Uç nokta her ikisini de tanımlar:

• İstekleri işleme temsilcisi.
• Rastgele meta veriler koleksiyonu. Meta veriler, her uç noktasına eklenen ilkelere ve yapılandırmaya göre çapraz kesme endişeleri uygulamak için kullanılır.

Terminal ara yazılımı etkili bir araç olabilir, ancak şunları gerekli olabilir:

• Önemli miktarda kodlama ve test.
• İstenen esneklik düzeyini elde etmek için diğer sistemlerle el ile tümleştirme.

Terminal ara yazılımı yazmadan önce yönlendirmeyle tümleştirmeyi göz önünde bulundurarak.

Eşleme ile tümleştirilmiş mevcut terminal ara yazılımı veya MapWhen genellikle yönlendirmeye yönelik bir uç nokta haline dönüşebilirsiniz. MapHealthChecks, router-ware için deseni gösterir:

• üzerinde bir uzantı yöntemi IEndpointRouteBuilder yazın.
• kullanarak iç içe geçmiş bir ara yazılım işlem hattı CreateApplicationBuilder oluşturun.
• Ara yazılımı yeni işlem hattına ekleme. Bu durumda, UseHealthChecks .
• Build ara yazılım işlem hattını bir içine RequestDelegate alın.
• Çağrısı Map ve yeni ara yazılım işlem hattını sağlama.
• tarafından uzantı yönteminden sağlanan Map oluşturucu nesnesini geri dönüş.

Aşağıdaki kod MapHealthChecks kullanımını gösterir:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    // Matches request to an endpoint.
    app.UseRouting();

    // Endpoint aware middleware. 
    // Middleware can use metadata from the matched endpoint.
    app.UseAuthentication();
    app.UseAuthorization();

    // Execute the matched endpoint.
    app.UseEndpoints(endpoints =>
    {
        // Configure the Health Check endpoint and require an authorized user.
        endpoints.MapHealthChecks("/healthz").RequireAuthorization();

        // Configure another endpoint, no authorization requirements.
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    });
}

Yukarıdaki örnek, oluşturucu nesnesinin neden önemli olduğunu gösterir. Oluşturucu nesnesinin iadesi, uygulama geliştiricinin uç nokta için yetkilendirme gibi ilkeleri yapılandırmalarına olanak sağlar. Bu örnekte sistem durumu denetimleri ara yazılımında yetkilendirme sistemiyle doğrudan tümleştirme yoktur.

Meta veri sistemi, terminal ara yazılımı kullanılarak genişletilebilirlik yazarlarının karşılaştığı sorunlara yanıt olarak oluşturulmuş. Her ara yazılım için yetkilendirme sistemiyle kendi tümleştirmesini uygulamak sorunludur.

URL eşleştirme

• Yönlendirmenin bir uç noktasına gelen istekle eşleşmesi işlemidir.
• URL yolundaki ve üst bilgilerde yer alan verileri temel alır.
• İstekte yer alan tüm verileri göz önünde bulundurarak genişletilmiş olabilir.

Yönlendirme ara yazılımı yürütülürken, geçerli istekten üzerinde bir istek Endpoint özelliğine bir ve yönlendirme HttpContext değerleri ayarlar:

• HttpContext.GetEndpoint çağrısı, uç noktayı alır.
• HttpRequest.RouteValues yol değerlerinin koleksiyonunu alır.

Yönlendirme ara yazılımdan sonra çalışan ara yazılım uç noktayı inceler ve eyleme geçebilirsiniz. Örneğin yetkilendirme ara yazılımı, yetkilendirme ilkesi için uç noktanın meta veri koleksiyonunu sorgular. İstek işleme işlem hattında tüm ara yazılım yürütülürken, seçilen uç noktanın temsilcisi çağrılır.

Uç nokta yönlendirmesinde yönlendirme sistemi, tüm gönderme kararlarının sorumluluğundadır. Ara yazılım, seçilen uç noktayı temel alan ilkeler uygulandığı için, aşağıdakilerin geçerli olduğu önemlidir:

• Gönderme veya güvenlik ilkelerinin uygulamasını etkileyebilecek herhangi bir karar yönlendirme sisteminin içinde yapılır.

URL eşleştirme yapılandırılabilir bir aşama kümesinde çalışır. Her aşamada çıkış bir eşleşme kümesidir. Eşleşme kümesi, bir sonraki aşamaya kadar daha fazla daraltıladır. Yönlendirme uygulaması, eşleşen uç noktalar için bir işleme sırası garanti değildir. Tüm olası eşleşmeler aynı anda işlenir. URL eşleştirme aşamaları aşağıdaki sırayla gerçekleşir. ASP.NET Core:

1. TÜM eşleşmeleri toplayarak URL yolunu uç noktalar kümesine ve yol şablonlarına göre işler.
2. Önceki listeyi alır ve rota kısıtlamaları uygulanmış olarak başarısız olan eşleşmeleri kaldırır.
3. Önceki listeyi alır ve MatcherPolicy örnekleri kümesi başarısız olan eşleşmeleri kaldırır.
4. Önceki listeden son bir karar vermek için Endpointselector kullanır.

Uç noktaların listesi şunlara göre önceliklendirilir:

• Routeendpoint. Order
• Yol şablonu önceliği

Tüm eşleşen uç noktalar, sonuna kadar her aşamada işlenir EndpointSelector . EndpointSelectorSon aşamadır. En iyi eşleşme ile eşleştirmelerle en yüksek öncelikli uç noktayı seçer. En iyi eşleşme ile aynı önceliğe sahip başka eşleşmeler varsa, belirsiz eşleşme özel durumu oluşur.

Yol önceliği, daha yüksek öncelikli olarak verilen daha belirli bir yol şablonuna göre hesaplanır. Örneğin, şablonları ve şunları göz önünde bulundurun /hello /{message} :

• Her ikisi de URL yoluyla eşleşir /hello .
• /hello daha özeldir ve bu nedenle daha yüksek önceliğe sahiptir.

Genel olarak, rota önceliği, uygulamada kullanılan URL şemaları türleri için en iyi eşleşmeyi seçme konusunda iyi bir iş olur. OrderBelirsizliği önlemek için yalnızca gerekli olduğunda kullanın.

Yönlendirme tarafından sunulan genişletilebilirlik türleri nedeniyle, yönlendirme sisteminin belirsiz yolların önünde işlem yapmak mümkün değildir. Yol şablonları gibi bir örnek düşünün /{message:alpha} /{message:int} :

• alphaKısıtlama yalnızca alfabetik karakterlerle eşleşir.
• intKısıtlama yalnızca sayılarla eşleşir.
• Bu şablonlar aynı rota önceliğine sahiptir, ancak her iki eşleşen tek URL yoktur.
• Yönlendirme sistemi başlangıçta bir belirsizlik hatası bildirse, bu geçerli kullanım durumunu engeller.

Yol şablonu önceliği ve uç nokta seçim sırası

Yol şablonu önceliği , her yol şablonuna, ne kadar belirli bir değere göre bir değer atayan bir sistemdir. Yol şablonu önceliği:

• Ortak durumlarda uç noktaların sırasını ayarlama ihtiyacını önler.
• Yönlendirme davranışının ortak Sense beklentilerini eşleştirmeye çalışır.

Örneğin, şablonları ve öğesini /Products/List düşünün /Products/{id} . /Products/ListURL yolundan daha iyi bir eşleşme olduğunu varsaymak mantıklı olacaktır /Products/{id} /Products/List . Bu, değişmez değer segmentinin /List parametre segmentinden daha iyi önceliğe sahip olduğu kabul edildiği için geçerlidir /{id} .

Önceliğin nasıl kullanılacağına ilişkin ayrıntılar, yönlendirme şablonlarının nasıl tanımlandığınıza bağlıdır:

• Daha fazla kesimli şablonlar daha belirgin olarak değerlendirilir.
• Değişmez değerli bir kesim, bir parametre segmentinden daha belirgin olarak değerlendirilir.
• Kısıtlaması olan bir parametre segmenti, olmadan birden fazla olarak değerlendirilir.
• Karmaşık bir kesim, kısıtlama içeren bir parametre segmenti olarak kabul edilir.
• Catch-all parametreleri en az özgüdür. Catch -All rotaları hakkında önemli bilgiler için bkz. route Template başvurusu .

tam değerler başvurusu için GitHub kaynak koda bakın.

URL oluşturma kavramları

URL oluşturma:

• , Yönlendirmenin bir yol değerleri kümesine göre bir URL yolu oluşturmalarına yönelik işlemdir.
• Uç noktalar ve bunlara erişen URL 'Ler arasında bir mantıksal ayrım sağlar.

Endpoint Routing LinkGenerator API 'yi içerir. LinkGenerator , dıtarafından kullanılabilen bir tek hizmettir. LinkGeneratorAPI, yürütülen bir istek bağlamı dışında kullanılabilir. Etiket Yardımcıları, HTML Yardımcıları ve eylem sonuçları gibi ' i kullanan Mvc. ıurlhelper ve senaryoları IUrlHelper , LinkGenerator bağlantı oluşturma yetenekleri sağlamak için API 'yi dahili olarak kullanır.

Bağlantı Oluşturucu, bir Adres ve Adres şemaları kavramıyla desteklenir. Adres şeması, bağlantı oluşturma için göz önünde bulundurmanız gereken uç noktaları belirlemenin bir yoludur. Örneğin, yol adı ve yol değerleri senaryoları birçok kullanıcı, denetleyicilerden ve Razor sayfalardan bir adres düzeni olarak uygulanır.

Bağlantı Oluşturucu Razor aşağıdaki genişletme yöntemleri aracılığıyla denetleyicilere ve sayfalara bağlanabilir:

• GetPathByAction
• GetUriByAction
• GetPathByPage
• GetUriByPage

Bu yöntemlerin aşırı yüklemeleri, içeren bağımsız değişkenleri kabul eder HttpContext . Bu yöntemler, URL. Action ve URL.Pageile işlevsel olarak eşdeğerdir, ancak ek esneklik ve seçenekler sunar.

GetPath*Yöntemleri Url.Action Url.Page , ve ' de, mutlak bir yol içeren bir URI oluşturmak için en çok benzerdir. GetUri*Yöntemler her zaman bir düzen ve konak içeren mutlak BIR URI oluşturur. Bir öğesini kabul eden yöntemler, HttpContext yürütülmekte olan istek bağlamında BIR URI oluşturur. Ortam yolu DEĞERLERI, URL taban yolu, şeması ve yürütülen istekten ana bilgisayar, geçersiz kılınmadıkça kullanılır.

LinkGenerator bir adresle çağırılır. URI oluşturma iki adımda gerçekleşir:

1. Adres, adresle eşleşen bir uç nokta listesine bağlanır.
2. Her uç nokta RoutePattern , sağlanan değerlerle eşleşen bir yol deseninin bulunana kadar değerlendirilir. Elde edilen çıktı, bağlantı oluşturucuya sağlanan diğer URI parçalarıyla birleştirilir ve döndürülür.

Tarafından sunulan yöntemler, LinkGenerator herhangi bir adres türü için standart bağlantı oluşturma yeteneklerini destekler. Bağlantı oluşturucuyu kullanmanın en kolay yolu, belirli bir adres türü için işlem gerçekleştiren genişletme yöntemlerine yöneliktir:

Ara yazılım örneği

Aşağıdaki örnekte, bir ara yazılım, LinkGenerator Mağaza ürünlerini listeleyen bir eylem yöntemine bağlantı oluşturmak için API 'yi kullanır. Ekleme tarafından bir sınıfa ve çağırarak bir GenerateLink uygulamadaki herhangi bir sınıf için kullanılabilir olan bağlantı oluşturucuyu kullanma:

public class ProductsLinkMiddleware
{
    private readonly LinkGenerator _linkGenerator;

    public ProductsLinkMiddleware(RequestDelegate next, LinkGenerator linkGenerator)
    {
        _linkGenerator = linkGenerator;
    }

    public async Task InvokeAsync(HttpContext httpContext)
    {
        var url = _linkGenerator.GetPathByAction("ListProducts", "Store");

        httpContext.Response.ContentType = "text/plain";

        await httpContext.Response.WriteAsync($"Go to {url} to see our products.");
    }
}

Rota şablonu başvurusu

İçindeki belirteçler {} , yol eşleştirildiği takdirde bağlanan rota parametrelerini tanımlar. Yol segmentinde birden fazla yol parametresi tanımlanabilir, ancak yol parametreleri bir sabit değer ile ayrılmalıdır. Örneğin, {controller=Home}{action=Index} ve arasında değişmez değer olmadığından geçerli bir yol değil {controller} {action} . Rota parametrelerinin bir adı olmalı ve ek öznitelikler belirtilmiş olabilir.

Yol parametrelerinden (örneğin, {id} ) ve yol ayırıcısından farklı bir metin, / URL içindeki metinle eşleşmelidir. Metin eşleştirme, büyük/küçük harfe duyarsız ve URL 'nin yolunun kodu çözülmüş gösterimine göre yapılır. Sabit bir yol parametresi sınırlayıcısından eşlemek { veya } karakteri tekrarlayarak sınırlayıcıdan kaçış. Örneğin {{ veya }} .

Yıldız işareti * veya çift yıldız işareti ** :

• URI 'nin geri kalanına bağlamak için bir yol parametresinin öneki olarak kullanılabilir.
• , Catch-all parametreleri olarak adlandırılır. Örneğin blog/{**slug} :
  • İle başlayan /blog ve bundan sonraki bir değere sahip tüm URI ile eşleşir.
  • Aşağıdaki değer, /blog başlık yolu değerine atanır.

public static void Main(string[] args)
{
   AppContext.SetSwitch("Microsoft.AspNetCore.Routing.UseCorrectCatchAllBehavior", 
                         true);
   CreateHostBuilder(args).Build().Run();
}
// Remaining code removed for brevity.

Catch-all parametreleri boş dizeyle de aynı olabilir.

Catch-all parametresi, yol ayırıcı karakterleri de dahil olmak üzere bir URL oluşturmak için kullanıldığında uygun karakterlerin bir kaçar / . Örneğin, foo/{*path} yol değerlerini içeren yol { path = "my/path" } oluşturulur foo/my%2Fpath . Atlanan eğik çizgiye göz önünde edin. Yol ayırıcı karakterlerini yuvarlaklaştırmak için ** Rota parametresi önekini kullanın. İle rota foo/{**path} { path = "my/path" } oluşturulur foo/my/path .

İsteğe bağlı bir dosya uzantısına sahip bir dosya adı yakalamaya deneyen URL desenlerinin ek konuları vardır. Örneğin, şablonu göz önünde bulundurun files/{filename}.{ext?} . Hem hem de için değerler olduğunda filename ext her iki değer de doldurulur. URL 'de yalnızca bir değeri filename varsa, sondaki değer isteğe bağlı olduğundan yol eşleşir . . Aşağıdaki URL 'Ler bu rota ile eşleşiyor:

• /files/myFile.txt
• /files/myFile

Yol parametreleri, parametre adından sonra bir eşittir işaretiyle () ayırarak varsayılan değer belirtilerek belirlenmiş varsayılan değerlere sahip olabilir = . Örneğin, {controller=Home} Home için varsayılan değer olarak tanımlar controller . Parametresi için URL 'de hiçbir değer yoksa varsayılan değer kullanılır. Yol parametreleri, parametre adının sonuna bir soru işareti () eklenerek isteğe bağlı olarak yapılır ? . Örneğin, id?. İsteğe bağlı değerler ve varsayılan yol parametreleri arasındaki fark şudur:

• Varsayılan değere sahip bir yol parametresi her zaman bir değer üretir.
• İsteğe bağlı bir parametre yalnızca istek URL 'SI tarafından bir değer sağlandığında bir değere sahip olur.

Rota parametrelerinin URL 'den bağlanan rota değeriyle eşleşmesi gereken kısıtlamaları olabilir. :Yol parametre adından sonra ekleme ve kısıtlama adı, bir rota parametresinde bir satır içi kısıtlamayı belirtir. Kısıtlama bağımsız değişkenler gerektiriyorsa, kısıtlama adından sonra parantez içine alınır (...) . Birden çok satır içi kısıtlama , başka bir : kısıtlama adı eklenerek belirtilebilir.

Kısıtlama adı ve bağımsız değişkenler, IInlineConstraintResolver IRouteConstraint URL işlemede kullanılmak üzere bir örneği oluşturmak için hizmetine geçirilir. Örneğin, yol şablonu blog/{article:minlength(10)} minlength bağımsız değişkenle bir kısıtlama belirtir 10 . Yol kısıtlamaları ve Framework tarafından sunulan kısıtlamaların bir listesi hakkında daha fazla bilgi için, route kısıtlama başvurusu bölümüne bakın.

Rota parametrelerinin ayrıca parametre dönüştürücüler de olabilir. Parametre dönüştürücüler, URL 'Ler için bağlantılar ve eşleşen eylemler ve sayfalar oluştururken parametrenin değerini dönüştürür. Benzer kısıtlamalar, : yol parametre adından sonra bir ve transformatör adı eklenerek, parametre dönüştürücüleri bir rota parametresine satır içi eklenebilir. Örneğin, yol şablonu blog/{article:slugify} bir slugify transformatör belirtir. Parametre dönüştürücüler hakkında daha fazla bilgi için bkz. Parameter transformatör başvurusu bölümü.

Aşağıdaki tabloda örnek yol şablonları ve bunların davranışları gösterilmektedir:

Bir şablon kullanmak genellikle yönlendirmeye en basit yaklaşımdır. Kısıtlamalar ve varsayılanlar, yol şablonu dışında da belirtilebilir.

Karmaşık segmentler

Karmaşık segmentler, en çok greksuz olmayan bir şekilde, sabit değer sınırlayıcılarını sağdan sola eşleştirerek işlenir. Örneğin, [Route("/a{b}c{d}")] karmaşık bir kesimdir. Karmaşık segmentler, onları başarılı bir şekilde kullanmak için anlaşılması gereken belirli bir şekilde çalışır. Bu bölümdeki örnek, sınırlayıcı metnin parametre değerleri içinde görünmemesinin neden karmaşık segmentlerin gerçekten iyi şekilde çalıştığını gösterir. Bir Regex kullanarak ve daha karmaşık durumlar için değerleri el ile ayıklamanız gerekir.

Bu, yönlendirmenin şablon ve URL yolu ile gerçekleştirdiği adımların bir özetidir /a{b}c{d} /abcd . , | Algoritmanın nasıl çalıştığını görselleştirmeye yardımcı olmak için kullanılır:

• İlk sabit değer, sağdan sola c . Bu nedenle /abcd , doğru bir şekilde aranır ve bulur /ab|c|d .
• Right () öğesine ait her şey d artık Route parametresiyle eşleştirildi {d} .
• Sonraki değişmez değer, sağdan sola a . Bu nedenle /ab|c|d , ayrıldığımız yerden başlayarak arama yapılır a /|a|b|c|d .
• Right ( b ) değeri artık Route parametresiyle eşleştirildi {b} .
• Kalan bir metin yok ve kalan yol şablonu yok, bu nedenle bu bir eşleşmedir.

Aynı şablonu ve URL yolunu kullanarak negatif bir durum örneği aşağıda verilmiştir /a{b}c{d} /aabcd . , | Algoritmanın nasıl çalıştığını görselleştirmeye yardımcı olmak için kullanılır. Bu durum, aynı algoritma tarafından açıklanan bir eşleşme değildir:

• İlk sabit değer, sağdan sola c . Bu nedenle /aabcd , doğru bir şekilde aranır ve bulur /aab|c|d .
• Right () öğesine ait her şey d artık Route parametresiyle eşleştirildi {d} .
• Sonraki değişmez değer, sağdan sola a . Bu nedenle /aab|c|d , ayrıldığımız yerden başlayarak arama yapılır a /a|a|b|c|d .
• Right ( b ) değeri artık Route parametresiyle eşleştirildi {b} .
• Bu noktada, kalan metin vardır a ancak algoritmanın ayrıştırılacak yol şablonu kalmadı, bu nedenle bu bir eşleşme değildir.

Eşleşen algoritma greyumsuzolmadığından:

• Her adımda mümkün olan en küçük metin miktarıyla eşleşir.
• Sınırlayıcı değerin parametre değerleri içinde göründüğü herhangi bir durum, eşleşmemelidir.

Normal ifadeler, eşleşen davranışları üzerinde çok daha fazla denetim sağlar.

Aynı zamanda yavaş eşleşmeolarak da bilinen Greedy eşleştirmesi, olası en büyük dizeyle eşleşir. Doyumsuz olmayan dize, olası en küçük dizeyle eşleşir.

Yol kısıtlama başvurusu

Yol kısıtlamaları, gelen URL 'de bir eşleşme meydana geldiğinde ve URL yolu yol değerlerinde simgeleştirilir yürütülür. Yol kısıtlamaları genellikle yol şablonu aracılığıyla ilişkili rota değerini inceler ve değerin kabul edilebilir olup olmadığı konusunda doğru veya yanlış bir karar vermez. Bazı rota kısıtlamaları, isteğin yönlendirilip yönlendirilmeyeceğini göz önünde bulundurmanız için yol değeri dışındaki verileri kullanır. Örneğin, HttpMethodRouteConstraint bir ISTEğI http fiiline bağlı olarak kabul edebilir veya reddedebilir. Kısıtlamalar, yönlendirme isteklerinde ve bağlantı oluşturmada kullanılır.

Aşağıdaki tabloda örnek yol kısıtlamaları ve beklenen davranışlar gösterilmektedir:

Birden çok, iki nokta üst üste sınırlı kısıtlama, tek bir parametreye uygulanabilir. Örneğin, aşağıdaki kısıtlama bir parametreyi 1 veya daha büyük bir tamsayı değeriyle kısıtlar:

[Route("users/{id:int:min(1)}")]
public User GetUserById(int id) { }

Kısıtlamalarda normal ifadeler

Normal ifadeler, Route kısıtlaması kullanılarak satır içi kısıtlamalar olarak belirtilebilir regex(...) . MapControllerRouteAilesindeki Yöntemler ayrıca Kısıtlamaların bir nesne sabit değerini de kabul eder. Bu form kullanılıyorsa, dize değerleri normal ifadeler olarak yorumlanır.

Aşağıdaki kod, bir satır içi Regex kısıtlaması kullanır:

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("{message:regex(^\\d{{3}}-\\d{{2}}-\\d{{4}}$)}",
        context => 
        {
            return context.Response.WriteAsync("inline-constraint match");
        });
 });

Aşağıdaki kod, bir Regex kısıtlaması belirtmek için bir nesne değişmez değeri kullanır:

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "people",
        pattern: "People/{ssn}",
        constraints: new { ssn = "^\\d{3}-\\d{2}-\\d{4}$", },
        defaults: new { controller = "People", action = "List", });
});

ASP.NET Core framework, RegexOptions.IgnoreCase | RegexOptions.Compiled | RegexOptions.CultureInvariant normal ifade oluşturucusuna ekler. RegexOptionsBu üyelerin açıklaması için bkz..

Normal ifadeler, Yönlendirme ve C# dili tarafından kullanılanlarla benzerlik olan sınırlayıcıları ve belirteçleri kullanır. Normal ifade belirteçlerinin atlanmalıdır. Normal ifadeyi ^\d{3}-\d{2}-\d{4}$ bir satır içi kısıtlamada kullanmak için aşağıdakilerden birini kullanın:

• Dizede \ belirtilen karakterleri, \\ dize kaçış karakterinden kaçınmak Için C# kaynak dosyasındaki karakter olarak değiştirin \ .
• Tam dize sabit değerleri.

Yönlendirme parametresi sınırlayıcı karakterlerini { ,,, } , [ ] ifadedeki karakterleri çift kaçış, örneğin {{ }} [[ ]] ,,,,. Aşağıdaki tabloda, bir normal ifade ve bunun kaçış sürümü gösterilmektedir:

Yönlendirmelerde kullanılan normal ifadeler, genellikle karakteriyle başlar ^ ve dizenin başlangıç konumuyla eşleşir. İfadeler genellikle $ karakteriyle biter ve dizenin sonuyla eşleşir. ^Ve $ karakterleri, normal ifadenin tüm yol parametresi değeri ile eşleştiğinden emin olun. ^Ve karakterleri olmadan $ normal ifade, dize içindeki herhangi bir alt dizeden eşleşir ve bu genellikle istenmeyen bir ifadedir. Aşağıdaki tabloda örnekler verilmektedir ve bunların eşleşmesinin neden eşleşmediği veya eşleşmemesi açıklanmaktadır:

normal ifade sözdizimi hakkında daha fazla bilgi için bkz. .NET Framework normal ifadeler.

Bir parametreyi bilinen olası değerler kümesiyle kısıtlamak için, normal bir ifade kullanın. Örneğin, {action:regex(^(list|get|create)$)} yalnızca action Rota değeri list ,, veya ile eşleşir get create . Kısıtlama sözlüğüne geçirilirse dize ^(list|get|create)$ eşdeğerdir. Bilinen kısıtlamalardan biriyle eşleşmeyen kısıtlama sözlüğünde geçirilen kısıtlamalar, normal ifadeler olarak da değerlendirilir. Bilinen kısıtlamaların biriyle eşleşmeyen bir şablon içinde geçirilen kısıtlamalar normal ifadeler olarak değerlendirilmez.

Özel yol kısıtlamaları

Özel yol kısıtlamaları arabirimi uygulayarak oluşturulabilir IRouteConstraint . IRouteConstraintArabirimi, Match true kısıtlama karşılanıp Aksi takdirde döndüren ' i içerir false .

Özel yol kısıtlamaları nadiren gereklidir. Özel bir yol kısıtlaması uygulamadan önce, model bağlama gibi alternatifleri göz önünde bulundurun.

ASP.NET Core kısıtlamalar klasörü, bir kısıtlama oluşturmaya yönelik iyi örnekler sağlar. Örneğin, Guidrouteconstraint.

Özel bir kullanmak için IRouteConstraint yol kısıtlama türü, uygulamanın hizmet kapsayıcısında kayıtlı olması gerekir ConstraintMap . ConstraintMap, Yol kısıtlama anahtarlarını IRouteConstraint Bu kısıtlamaları doğrulayan uygulamalarla eşleyen bir sözlüktür. Bir uygulama ConstraintMap , Startup.ConfigureServices hizmetlerin bir parçası olarak ' de güncelleştirilir . AddRouting çağrısı veya RouteOptions doğrudan ile yapılandırma services.Configure<RouteOptions> . Örnek:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    services.AddRouting(options =>
    {
        options.ConstraintMap.Add("customName", typeof(MyCustomConstraint));
    });
}

Önceki kısıtlama aşağıdaki kodda uygulanır:

[Route("api/[controller]")]
[ApiController]
public class TestController : ControllerBase
{
    // GET /api/test/3
    [HttpGet("{id:customName}")]
    public IActionResult Get(string id)
    {
        return ControllerContext.MyDisplayRouteInfo(id);
    }

    // GET /api/test/my/3
    [HttpGet("my/{id:customName}")]
    public IActionResult Get(int id)
    {
        return ControllerContext.MyDisplayRouteInfo(id);
    }
}

Mydisplayrouteınfo , Rick.Docs. Samples. routeınfo NuGet paketi tarafından sağlanır ve rota bilgilerini görüntüler.

Uygulamasının uygulanması, MyCustomConstraint 0 bir rota parametresine uygulanmasını engeller:

class MyCustomConstraint : IRouteConstraint
{
    private Regex _regex;

    public MyCustomConstraint()
    {
        _regex = new Regex(@"^[1-9]*$",
                            RegexOptions.CultureInvariant | RegexOptions.IgnoreCase,
                            TimeSpan.FromMilliseconds(100));
    }
    public bool Match(HttpContext httpContext, IRouter route, string routeKey,
                      RouteValueDictionary values, RouteDirection routeDirection)
    {
        if (values.TryGetValue(routeKey, out object value))
        {
            var parameterValueString = Convert.ToString(value,
                                                        CultureInfo.InvariantCulture);
            if (parameterValueString == null)
            {
                return false;
            }

            return _regex.IsMatch(parameterValueString);
        }

        return false;
    }
}

Yukarıdaki kod:

• 0 {id} Yolun segmentinde engeller.
• , Özel bir kısıtlamayı uygulamaya yönelik temel bir örnek sağlamak için gösterilmektedir. Bu, bir üretim uygulamasında kullanılmamalıdır.

Aşağıdaki kod, içeren bir öğenin işlenmesini önlemek için daha iyi bir yaklaşımdır id 0 :

[HttpGet("{id}")]
public IActionResult Get(string id)
{
    if (id.Contains('0'))
    {
        return StatusCode(StatusCodes.Status406NotAcceptable);
    }

    return ControllerContext.MyDisplayRouteInfo(id);
}

Yukarıdaki kodda yaklaşım üzerinde aşağıdaki avantajlar bulunur MyCustomConstraint :

• Özel bir kısıtlama gerektirmez.
• Yol parametresi içerdiğinde daha açıklayıcı bir hata döndürür 0 .

Parametre transformatörü başvurusu

Parametre dönüştürücüler:

• Kullanarak bağlantı oluştururken yürütün LinkGenerator .
• Uygulayın Microsoft.AspNetCore.Routing.IOutboundParameterTransformer .
• Kullanılarak yapılandırılır ConstraintMap .
• Parametrenin yol değerini alın ve yeni bir dize değerine dönüştürün.
• Oluşturulan bağlantıda Dönüştürülmüş değerin kullanılmasına neden olacak.

Örneğin, yol düzeninde bir özel slugify parametre transformatörü blog\{article:slugify} Url.Action(new { article = "MyTestArticle" }) oluşturur blog\my-test-article .

Aşağıdaki uygulamayı göz önünde bulundurun IOutboundParameterTransformer :

public class SlugifyParameterTransformer : IOutboundParameterTransformer
{
    public string TransformOutbound(object value)
    {
        if (value == null) { return null; }

        return Regex.Replace(value.ToString(), 
                             "([a-z])([A-Z])",
                             "$1-$2",
                             RegexOptions.CultureInvariant,
                             TimeSpan.FromMilliseconds(100)).ToLowerInvariant();
    }
}

Bir parametre transformatörü bir yol düzeninde kullanmak için, şunu içinde kullanarak yapılandırın ConstraintMap Startup.ConfigureServices :

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    services.AddRouting(options =>
    {
        options.ConstraintMap["slugify"] = typeof(SlugifyParameterTransformer);
    });
}

ASP.NET Core framework, bir uç noktanın çözümlediği urı 'yi dönüştürmek için parametre dönüştürücüler kullanır. Örneğin, parametre dönüştürücüler,,, ve ile eşleştirmek için kullanılan rota değerlerini dönüştürür area controller action page .

routes.MapControllerRoute(
    name: "default",
    template: "{controller:slugify=Home}/{action:slugify=Index}/{id?}");

Önceki yol şablonuyla, eylem SubscriptionManagementController.GetAll URI ile eşleştirilir /subscription-management/get-all . Bir parametre transformatörü bir bağlantı oluşturmak için kullanılan rota değerlerini değiştirmez. Örneğin, Url.Action("GetAll", "SubscriptionManagement") çıktılar /subscription-management/get-all .

ASP.NET Core, oluşturulan yollarla parametre dönüştürücüler kullanmak için apı kuralları sağlar:

• Microsoft.AspNetCore.Mvc.ApplicationModels.RouteTokenTransformerConventionMVC kuralı, uygulamadaki tüm öznitelik yollarına belirtilen bir parametre transformatörü uygular. Parametre transformatörü, öznitelik yol belirteçlerini değiştirildiklerinde dönüştürür. Daha fazla bilgi için bkz. belirteç değişimini özelleştirmek için bir parametre transformatörü kullanma.
• Razor Sayfalar PageRouteTransformerConvention API kuralını kullanır. Bu kural, belirtilen bir parametre transformatörü otomatik olarak bulunan tüm Razor sayfalara uygular. Parametre transformatörü, sayfa yollarının klasör ve dosya adı segmentlerini dönüştürür Razor . Daha fazla bilgi için bkz. sayfa yollarını özelleştirmek için bir parametre transformatörü kullanma.

URL oluşturma başvurusu

Bu bölüm, URL oluşturma tarafından uygulanan algoritmanın başvurusunu içerir. Uygulamada, URL oluşturma 'nın çoğu karmaşık örneği denetleyicileri veya sayfaları kullanır Razor . Daha fazla bilgi için bkz. denetleyicilerde yönlendirme .

URL oluşturma işlemi Linkgenerator. GetPathByAddress veya benzer bir yöntem çağrısıyla başlar. Yöntemi bir adres, bir rota değerleri kümesi ve isteğe bağlı olarak geçerli istek hakkında bilgi ile birlikte sağlanır HttpContext .

İlk adım, adresin türüyle eşleşen bir aday uç nokta kümesini çözümlemek için adresi kullanmaktır IEndpointAddressScheme<TAddress> .

Aday kümesi adres şeması tarafından bulunduğunda, uç noktalar bir URL oluşturma işlemi başarılı olana kadar sıralanır ve işlenir. URL oluşturma belirsizlikleri için Denetim yapmaz , döndürülen ilk sonuç son sonuçdur.

Günlüğe kaydetme ile URL oluşturma sorunlarını giderme

URL oluşturma sorunlarını gidermeye yönelik ilk adım, günlük düzeyini Microsoft.AspNetCore.Routing olarak ayarlıyor TRACE . LinkGenerator işleme hakkında birçok ayrıntıyı günlüğe kaydeder ve bu da sorunları gidermek için yararlı olabilir.

URL oluşturma hakkında ayrıntılı bilgi için bkz. URL oluşturma başvurusu .

Adresler

Adresler, bağlantı oluşturucuya bir çağrıyı bir aday uç noktası kümesine bağlamak için kullanılan URL oluşturma kavramıdır.

Adresler, varsayılan olarak iki uygulama ile birlikte gelen Genişletilebilir bir kavramdır:

• Şu adres olarak uç nokta adı ( string ) kullanılıyor:
  • MVC 'nin yol adına benzer işlevsellik sağlar.
  • IEndpointNameMetadataMeta veri türünü kullanır.
  • Belirtilen dizeyi tüm kayıtlı uç noktaların meta verilerinde çözer.
  • Birden fazla uç nokta aynı adı kullanıyorsa, başlangıçta bir özel durum oluşturur.
  • Denetleyicilerin ve sayfaların dışında genel amaçlı kullanım için önerilir Razor .
• Adres olarak yol değerlerini ( RouteValuesAddress ) kullanma:
  • Denetleyiciler ve Razor sayfalar için eskı URL oluşturmaya benzer işlevler sağlar.
  • Genişletmek ve hata ayıklamak için çok karmaşık.
  • IUrlHelper, Etiket yardımcıları, HTML Yardımcıları, eylem sonuçları vb. tarafından kullanılan uygulamayı sağlar.

Adres şemasının rolü, rastgele ölçütlere göre adres ve eşleşen uç noktalar arasındaki ilişkiyi oluşturmak için kullanılır:

• Uç nokta adı şeması, temel bir sözlük araması gerçekleştirir.
• Yol değerleri şeması, set algoritmasının karmaşık bir en iyi alt kümesine sahiptir.

Çevresel değerler ve açık değerler

Yönlendirme geçerli istekten, geçerli isteğin rota değerlerine erişir HttpContext.Request.RouteValues . Geçerli istekle ilişkili değerler çevresel değerler olarak adlandırılır. Netlik amacı doğrultusunda, belgeler yöntemlere geçirilen yol değerlerini açık değerler olarak ifade eder.

Aşağıdaki örnek, ortam değerlerini ve açık değerleri gösterir. Geçerli istekten ve açık değerlerden çevresel değerler sağlar: { id = 17, } :

public class WidgetController : Controller
{
    private readonly LinkGenerator _linkGenerator;

    public WidgetController(LinkGenerator linkGenerator)
    {
        _linkGenerator = linkGenerator;
    }

    public IActionResult Index()
    {
        var url = _linkGenerator.GetPathByAction(HttpContext,
                                                 null, null,
                                                 new { id = 17, });
        return Content(url);
    }

Yukarıdaki kod:

• Döndürdüğü /Widget/Index/17
• LinkGenerator Dıaracılığıyla alır.

Aşağıdaki kod hiçbir çevresel değer ve açık değer sağlar: { controller = "Home", action = "Subscribe", id = 17, } :

public IActionResult Index2()
{
    var url = _linkGenerator.GetPathByAction("Subscribe", "Home",
                                             new { id = 17, });
    return Content(url);
}

Önceki yöntem şunu döndürür /Home/Subscribe/17

Aşağıdaki kod WidgetController döndürmektedir /Widget/Subscribe/17 :

var url = _linkGenerator.GetPathByAction("Subscribe", null,
                                         new { id = 17, });

Aşağıdaki kod, denetleyiciyi geçerli istekteki çevresel değerlerden ve açık değerlerde sağlar: { action = "Edit", id = 17, } :

public class GadgetController : Controller
{
    public IActionResult Index()
    {
        var url = Url.Action("Edit", new { id = 17, });
        return Content(url);
    }

Yukarıdaki kodda:

• /Gadget/Edit/17 döndürülür.
• Url alır IUrlHelper .
• Action
  bir eylem yöntemi için mutlak bir yol içeren bir URL oluşturur. URL, belirtilen action adı ve değerleri içerir route .

Aşağıdaki kod, geçerli istekten ve açık değerlerden çevresel değerler sağlar: { page = "./Edit, id = 17, } :

public class IndexModel : PageModel
{
    public void OnGet()
    {
        var url = Url.Page("./Edit", new { id = 17, });
        ViewData["URL"] = url;
    }
}

Önceki kod, url /Edit/17 düzenleme Razor sayfası aşağıdaki sayfa yönergesini içerdiğinde olarak ayarlanır:

@page "{id:int}"

Düzenleme sayfasında "{id:int}" yol şablonu yoksa, url olur /Edit?id=17 .

MVC 'nin davranışı, IUrlHelper burada açıklanan kurallara ek olarak bir karmaşıklık katmanı ekler:

• IUrlHelper her zaman geçerli istekten çevresel değerler olarak yol değerlerini sağlar.
• Iurlhelper. Action , action controller Geliştirici tarafından geçersiz kılınmadığı sürece her zaman geçerli ve yol değerlerini açık değerler olarak kopyalar.
• IUrlHelper.Page , page geçersiz kılınmadığı sürece, her zaman geçerli yol değerini açık bir değer olarak kopyalar.
• IUrlHelper.Page her zaman geçersiz handler null kılınmadığı sürece açık değerler olarak geçerli yol değerini geçersiz kılar.

MVC kendi kurallarını takip ettiğinden, kullanıcılar genellikle çevresel değerlerinin davranış ayrıntılarına göre görünür. Geçmiş ve uyumluluk nedenleriyle,,, ve gibi belirli rota action değerlerinin controller page handler kendi özel durum davranışları vardır.

Tarafından sunulan eşdeğer işlevsellik LinkGenerator.GetPathByAction ve LinkGenerator.GetPathByPage Bu bozuklukları IUrlHelper uyumluluk açısından çoğaltır.

URL oluşturma işlemi

Aday uç noktalar kümesi bulunduğunda, URL oluşturma algoritması:

• Son noktaları yinelemeli olarak işler.
• İlk başarılı sonucu döndürür.

Bu işlemdeki ilk adıma Rota değeri ınvalidation adı verilir. Rota değeri geçersiz kılma, yönlendirmenin çevresel değerlerden hangi rota değerlerinin kullanılması gerektiğini ve göz ardı edileceğine yönelik bir işlemdir. Her ortam değeri, açık değerlerle birlikte değerlendirilir ve yok sayılır.

Ortam değerlerinin rolünü düşünmenin en iyi yolu, bazı yaygın durumlarda, yazma uygulama geliştiricilerinin kaydedilmesini denedikleri değerlerdir. Geleneksel olarak, ortam değerlerinin yararlı olduğu senaryolar MVC ile ilgilidir:

• Aynı denetleyicideki başka bir eyleme bağlantı sırasında, denetleyicinin adının belirtilmesi gerekmez.
• Aynı alandaki başka bir denetleyiciye bağlanırken, alan adının belirtilmesi gerekmez.
• Aynı eylem yöntemine bağlanırken, rota değerlerinin belirtilmesi gerekmez.
• Uygulamanın başka bir bölümüne bağlanırken, uygulamanın o bölümünde anlamı olmayan rota değerlerini yürütmek istemezsiniz.

Ya da LinkGenerator IUrlHelper Bu dönüşe yapılan çağrılar null genellikle yol değeri doğrulaması anlaşılmadığında oluşur. Yolun sorunu çözüp çözmediğini görmek için daha fazla yol değeri belirtip yol değerlerini geçersiz kılma sorunlarını giderin.

Rota değeri geçersiz kılma, uygulamanın URL şeması, soldan sağa doğru oluşturulmuş bir hiyerarşi ile hiyerarşik olduğu varsayımıyla birlikte çalışıyor. {controller}/{action}/{id?}Bu uygulamada nasıl çalıştığını daha kolay bir şekilde öğrenmek için temel denetleyici yönlendirme şablonunu göz önünde bulundurun. Bir değer değişikliği , sağda görünen tüm rota değerlerini geçersiz kılar . Bu, hiyerarşiyle ilgili varsayımını yansıtır. Uygulamanın için bir ortam değeri varsa id ve işlem için farklı bir değer belirtiyorsa controller :

• id``{controller}, öğesinin solunda olduğu için yeniden kullanılamaz {id?} .

Bu ilkeyi gösteren bazı örnekler:

• Açık değerler için bir değer içeriyorsa id , ortam değeri id yok sayılır. Ve için çevresel değerler controller action kullanılabilir.
• Açık değerler için bir değer içeriyorsa action , için herhangi bir ortam değeri action yok sayılır. için ortam controller değerleri kullanılabilir. için açık action değer için ortam değerinden farklı action id ise, değer kullanılmaz. için açık değer action için ortam değeriyle aynı action id ise, değeri kullanılabilir.
• Açık değerler için bir değer controller içeriyorsa, için herhangi bir ortam değeri controller yoksayılır. için açık değer için ortam değerinden farklı ise ve controller değerleri controller action id kullanılmaz. için açık değer controller için ortam değeriyle aynı ise ve controller değerleri action id kullanılabilir.

Öznitelik yollarının ve ayrılmış geleneksel yolların varlığıyla bu işlem daha da karmaşıktır. Yol parametrelerini kullanarak hiyerarşi {controller}/{action}/{id?} belirtme gibi denetleyici geleneksel yolları. Denetleyicilere ve Sayfalara ayrılmış geleneksel yollar ve öznitelik yolları Razor için:

• Yol değerleri hiyerarşisi vardır.
• Bunlar şablonda görünmez.

Bu gibi durumlarda URL oluşturma, gerekli değerler kavramını tanımlar. Denetleyiciler ve Sayfalar tarafından oluşturulan uç noktaların, yol değeri geçersiz kılınma Razor çalışmasına izin verecek şekilde belirtilen gerekli değerleri vardır.

Rota değeri geçersiz kılınma algoritması ayrıntılı olarak:

• Gerekli değer adları yol parametreleriyle bir araya alınır ve soldan sağa işlenir.
• Her parametre için ortam değeri ve açık değer karşılaştırıldı:
  • Ortam değeri ve açık değer aynı ise işlem devam eder.
  • Ortam değeri mevcutsa ve açık değer mevcut değilse, URL'yi oluşturmada ortam değeri kullanılır.
  • Ortam değeri mevcut değilse ve açık değer ise, ortam değerini ve sonraki tüm çevresel değerleri reddedin.
  • Ortam değeri ve açık değer mevcutsa ve iki değer farklı ise, ortam değerini ve sonraki tüm çevresel değerleri reddedin.

Bu noktada, URL oluşturma işlemi yol kısıtlamalarını değerlendirmeye hazırdır. Kabul edilen değerler kümesi, kısıtlamalara sağlanan parametre varsayılan değerleriyle birleştirilmiştir. Kısıtlamaların hepsi geçerse işlem devam eder.

Ardından, rota şablonunu genişletmek için kabul edilen değerler kullanılabilir. Yol şablonu işlenir:

• Soldan sağa.
• Her parametrenin yerine kabul edilen değeri vardır.
• Aşağıdaki özel durumlarda:
  • Kabul edilen değerlerin bir değeri yoksa ve parametrenin varsayılan değeri varsa varsayılan değer kullanılır.
  • Kabul edilen değerlerin bir değeri eksikse ve parametresi isteğe bağlı ise işleme devam eder.
  • Eksik isteğe bağlı parametrenin sağ tarafından bir yol parametresinin değeri varsa işlem başarısız olur.
  • Bitişik varsayılan değerli parametreler ve isteğe bağlı parametreler mümkün olduğunca daraltılmış olur.

Açıkça sağlanan ve yol kesimiyle eşleşmeen değerler sorgu dizesine eklenir. Aşağıdaki tabloda yol şablonu kullanırken elde edilen sonuç yer {controller}/{action}/{id?} almaktadır.

Rota değeri geçersiz kılınma sorunları

3.0 ASP.NET Core önceki sürümlerde kullanılan bazı URL ASP.NET Core şemaları, URL oluşturma ile iyi çalışmıyor. ASP.NET Core ekibi, gelecek bir sürümde bu ihtiyaçları karşılamak için özellikler eklemeyi planlıyor. Şimdilik en iyi çözüm eski yönlendirmeyi kullanmaktır.

Aşağıdaki kod, yönlendirme tarafından desteklen bir URL oluşturma şeması örneği gösterir.

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute("default", 
                                     "{culture}/{controller=Home}/{action=Index}/{id?}");
    endpoints.MapControllerRoute("blog", "{culture}/{**slug}", 
                                      new { controller = "Blog", action = "ReadPost", });
});

Önceki kodda yönlendirme culture parametresi yerelleştirme için kullanılır. Parametrenin her zaman culture ortam değeri olarak kabul edile bir değere sahip olmak isteğidir. Ancak gerekli culture değerlerin çalışma yolu nedeniyle parametresi ortam değeri olarak kabul edilmemektedir:

• Yol "default" şablonunda, culture yol parametresi sol controller taraftadır, bu nedenle olarak yapılan değişiklikler geçersiz controller kılınmaz. culture
• Yol "blog" şablonunda yol culture parametresinin, gerekli değerlerde görünen controller sağ tarafından olduğu kabul edilir.

Uç nokta meta verilerini yapılandırma

Aşağıdaki bağlantılar uç nokta meta verilerini yapılandırma hakkında bilgi sağlar:

• Uç nokta yönlendirme ile Cors'u etkinleştirme
• Özel öznitelik kullanan IAuthorizationPolicyProvider [MinimumAgeAuthorize] örneği
• Kimlik doğrulamasını [Authorize] özniteliğiyle test etmek
• RequireAuthorization
• [Authorize] özniteliğiyle düzeni seçme
• [Authorize] özniteliğini kullanarak ilkeleri uygulama
• ASP.NET Core'de rol tabanlı yetkilendirme

RequireHost ile yollarda konak eşleştirme

RequireHost belirtilen ana bilgisayarı gerektiren yol için bir kısıtlama uygular. veya RequireHost [Host] parametresi şöyle olabilir:

• Konak: www.domain.com , herhangi bir bağlantı www.domain.com noktasıyla eşler.
• Joker karakterli konak: *.domain.com , , veya ile herhangi bir bağlantı noktası üzerinde www.domain.com subdomain.domain.com www.subdomain.domain.com eşler.
• Bağlantı noktası: *:5000 , herhangi bir konakla 5000 bağlantı noktasıyla eşler.
• Konak ve bağlantı noktası: www.domain.com:5000 veya , konak ve bağlantı *.domain.com:5000 noktasıyla eştir.

veya kullanılarak birden çok parametre RequireHost [Host] belirtilebilir. Kısıtlama, parametrelerden herhangi biri için geçerli olan konaklarla eşler. Örneğin, , [Host("domain.com", "*.domain.com")] domain.com ve ile www.domain.com subdomain.domain.com eşler.

Aşağıdaki kod, RequireHost yolda belirtilen ana bilgisayarı gerektirmek için kullanır:

public void Configure(IApplicationBuilder app)
{
    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", context => context.Response.WriteAsync("Hi Contoso!"))
            .RequireHost("contoso.com");
        endpoints.MapGet("/", context => context.Response.WriteAsync("AdventureWorks!"))
            .RequireHost("adventure-works.com");
        endpoints.MapHealthChecks("/healthz").RequireHost("*:8080");
    });
}

Aşağıdaki kod, belirtilen [Host] konaklardan herhangi birini gerektirmek için denetleyicide özniteliğini kullanır:

[Host("contoso.com", "adventure-works.com")]
public class ProductController : Controller
{
    public IActionResult Index()
    {
        return ControllerContext.MyDisplayRouteInfo();
    }

    [Host("example.com:8080")]
    public IActionResult Privacy()
    {
        return ControllerContext.MyDisplayRouteInfo();
    }
}

özniteliği [Host] hem denetleyici hem de eylem yöntemine uygulandığında:

• Eylemde özniteliği kullanılır.
• Denetleyici özniteliği yoksayılır.

Yönlendirme için performans kılavuzu

Yönlendirmenin çoğu performansı artırmak ASP.NET Core 3.0'da güncelleştirildi.

Bir uygulamanın performans sorunları olduğunda, sorun genellikle yönlendirmeden şüphe olur. Yönlendirmenin nedeni, denetleyiciler ve Sayfalar gibi çerçevelerin çerçeve içinde günlük iletilerine harcanan zamanı Razor bildirmesidir. Denetleyiciler tarafından bildirilen süre ile isteğin toplam süresi arasında önemli bir fark olduğunda:

• Geliştiriciler, sorunun kaynağı olarak uygulama kodunu ortadan kaldırmış olur.
• Bunun nedeninin yönlendirme olduğunu varsayma yaygın bir durum olabilir.

Binlerce uç nokta kullanılarak yönlendirme performansı test edilir. Tipik bir uygulamanın yalnızca çok büyük olmasıyla bir performans sorunuyla karşılaşması pek olası değildir. Yavaş yönlendirme performansının en yaygın kök nedeni genellikle kötü performansa neden olan özel bir ara yazılımdır.

Aşağıdaki kod örneği, gecikme kaynağını daraltmak için temel bir tekniği gösteriyor:

public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
{
    app.Use(next => async context =>
    {
        var sw = Stopwatch.StartNew();
        await next(context);
        sw.Stop();

        logger.LogInformation("Time 1: {ElapsedMilliseconds}ms", sw.ElapsedMilliseconds);
    });

    app.UseRouting();

    app.Use(next => async context =>
    {
        var sw = Stopwatch.StartNew();
        await next(context);
        sw.Stop();

        logger.LogInformation("Time 2: {ElapsedMilliseconds}ms", sw.ElapsedMilliseconds);
    });

    app.UseAuthorization();

    app.Use(next => async context =>
    {
        var sw = Stopwatch.StartNew();
        await next(context);
        sw.Stop();

        logger.LogInformation("Time 3: {ElapsedMilliseconds}ms", sw.ElapsedMilliseconds);
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Timing test.");
        });
    });
}

Zaman yönlendirme:

• Her ara yazılımı önceki kodda gösterilen zamanlama ara yazılımı kopyasıyla birlikte kopyalayın.
• Zamanlama verileriyle kod arasında ilişki için benzersiz bir tanımlayıcı ekleyin.

Bu, önemli olduğunda gecikmeyi daraltmanın temel bir yolu, örneğin, 'den 10ms fazladır. Time 2Raporlardan, ara yazılım içinde harcanan zamanı Time 1 UseRouting çıkarma.

Aşağıdaki kod, önceki zamanlama koduna daha küçük bir yaklaşım kullanır:

public sealed class MyStopwatch : IDisposable
{
    ILogger<Startup> _logger;
    string _message;
    Stopwatch _sw;

    public MyStopwatch(ILogger<Startup> logger, string message)
    {
        _logger = logger;
        _message = message;
        _sw = Stopwatch.StartNew();
    }

    private bool disposed = false;


    public void Dispose()
    {
        if (!disposed)
        {
            _logger.LogInformation("{Message }: {ElapsedMilliseconds}ms",
                                    _message, _sw.ElapsedMilliseconds);

            disposed = true;
        }
    }
}

public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
{
    int count = 0;
    app.Use(next => async context =>
    {
        using (new MyStopwatch(logger, $"Time {++count}"))
        {
            await next(context);
        }

    });

    app.UseRouting();

    app.Use(next => async context =>
    {
        using (new MyStopwatch(logger, $"Time {++count}"))
        {
            await next(context);
        }
    });

    app.UseAuthorization();

    app.Use(next => async context =>
    {
        using (new MyStopwatch(logger, $"Time {++count}"))
        {
            await next(context);
        }
    });

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            await context.Response.WriteAsync("Timing test.");
        });
    });
}

Pahalı olabilecek yönlendirme özellikleri

Aşağıdaki liste, temel yol şablonlarıyla karşılaştırıldığında görece pahalı olan yönlendirme özellikleri hakkında içgörü sağlar:

• Normal ifadeler: Karmaşık veya az miktarda girişle uzun süre çalışan normal ifadeler yazmak mümkündür.

• Karmaşık segmentler ( {x}-{y}-{z} ):

  • Normal bir URL yolu kesimini ayrıştırmaktan çok daha pahalıdır.
  • Çok daha fazla alt dizenin ayrılırken sonuç.
  • Karmaşık kesim mantığı, 3.0 yönlendirme ASP.NET Core güncelleştirmesinde güncelleştirilmedi.

• Zaman uyumlu veri erişimi: Birçok karmaşık uygulama, yönlendirmelerinin bir parçası olarak veritabanı erişimine sahip olur. ASP.NET Core 2.2 ve önceki yönlendirmeler veritabanı erişim yönlendirmeyi desteklemek için doğru genişletilebilirlik noktalarını sağlamayabilirsiniz. Örneğin, IRouteConstraint ve IActionConstraint zaman uyumlu olur. ve gibi genişletilebilirlik MatcherPolicy EndpointSelectorContext noktaları zaman uyumsuz.

Kitaplık yazarları için rehberlik

Bu bölüm, yönlendirmenin üzerinde çalışan kitaplık yazarlarının kılavuzlarını içerir. Bu ayrıntılar, uygulama geliştiricilerinin yönlendirmeyi genişleten kitaplıkları ve çerçeveleri kullanarak iyi bir deneyim yaşamalarını sağlamak için tasarlanmıştır.

Uç noktaları tanımlama

URL eşleştirmesi için yönlendirme kullanan bir çerçeve oluşturmak için, üzerine derlemesi yapılan bir kullanıcı deneyimi tanımlayarak UseEndpoints başlayabilirsiniz.

üzerinde DO IEndpointRouteBuilder derlemesi. Bu, kullanıcıların çerçevenizi karışıklık olmadan diğer ASP.NET Core oluşturmalarını sağlar. Her ASP.NET Core şablonu yönlendirmeyi içerir. Yönlendirmenin kullanıcılar için mevcut ve tanıdık olduğunu varsayalım.

app.UseEndpoints(endpoints =>
{
    // Your framework
    endpoints.MapMyFramework(...);

    endpoints.MapHealthChecks("/healthz");
});

DO, uygulayan çağrısından korumalı bir MapMyFramework(...) somut tür iade IEndpointConventionBuilder ediyor. Çoğu çerçeve Map... yöntemi bu düzeni kullanır. IEndpointConventionBuilderArabirim:

• Meta verilerin birliğini sağlar.
• Çeşitli uzantı yöntemleri tarafından hedeflidir.

Kendi türlerinizi bildirerek oluşturucuya çerçeveye özgü kendi işlevselliğinizi eklemenize olanak sağlar. Çerçeve tarafından bildirilen bir oluşturucu sarmalar ve buna çağrılar iletir.

app.UseEndpoints(endpoints =>
{
    // Your framework
    endpoints.MapMyFramework(...).RequireAuthorization()
                                 .WithMyFrameworkFeature(awesome: true);

    endpoints.MapHealthChecks("/healthz");
});

Kendi yazmanızı EndpointDataSource DÜŞÜNÜN. EndpointDataSource , uç nokta koleksiyonunu bildirime ve güncelleştirmeye uygun alt düzey temel öğedir. EndpointDataSource , denetleyiciler ve Sayfalar tarafından kullanılan güçlü bir Razor API'dir.

Yönlendirme testlerinde, güncelleştirilen bir veri kaynağının temel bir örneği yer alan.

Varsayılan olarak kaydetmeyi EndpointDataSource DENEMEYİN. Kullanıcıların çerçevenizi 'a kaydetmesini UseEndpoints gerektir. Yönlendirme anlayışı, varsayılan olarak hiçbir şeyin dahil olmadığını ve uç UseEndpoints noktaların kaydedilene yer olduğudur.

Yönlendirmeyle tümleşik ara yazılım oluşturma

Meta veri türlerini arabirim olarak tanımlamayı DÜŞÜNÜN.

YAPIN: Sınıflarda ve yöntemlerde meta veri türlerini öznitelik olarak kullanabilirsiniz.

public interface ICoolMetadata
{
    bool IsCool { get; }
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class CoolMetadataAttribute : Attribute, ICoolMetadata
{
    public bool IsCool => true;
}

Denetleyiciler ve Sayfalar gibi Razor çerçeveler, türlere ve yöntemlere meta veri özniteliklerini uygulamayı destekler. Meta veri türlerini bildirersiniz:

• Bunları öznitelik olarak erişilebilir hale.
• Kullanıcıların çoğu öznitelikleri uygulama hakkında bilgi sahibidir.

Bir meta veri türünü arabirim olarak bildirerek başka bir esneklik katmanı daha ebilirsiniz:

• Arabirimler birleştirilebilir.
• Geliştiriciler, birden çok ilkeyi birleştiren kendi türlerini bildirer.

YAPIN: Aşağıdaki örnekte gösterildiği gibi meta verileri geçersiz kılmayı mümkün kılın:

public interface ICoolMetadata
{
    bool IsCool { get; }
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class CoolMetadataAttribute : Attribute, ICoolMetadata
{
    public bool IsCool => true;
}

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
public class SuppressCoolMetadataAttribute : Attribute, ICoolMetadata
{
    public bool IsCool => false;
}

[CoolMetadata]
public class MyController : Controller
{
    public void MyCool() { }

    [SuppressCoolMetadata]
    public void Uncool() { }
}

Bu yönergeleri izlemenin en iyi yolu, işaretçi meta verilerini tanımlamaktan kaçınmaktır:

• Yalnızca meta veri türünün varlığını aramayın.
• Meta verilerde bir özellik tanımlayın ve özelliğini kontrol edin.

Meta veri koleksiyonu sıralıdır ve önceliğe göre geçersiz kılmayı destekler. Denetleyiciler durumunda, eylem yönteminde meta veriler en özeldir.

DO, yönlendirme ile ve yönlendirme olmadan ara yazılımı yararlı hale sağlar.

app.UseRouting();

app.UseAuthorization(new AuthorizationPolicy() { ... });

app.UseEndpoints(endpoints =>
{
    // Your framework
    endpoints.MapMyFramework(...).RequireAuthorization();
});

Bu kılavuza örnek olarak ara yazılımı UseAuthorization göz önünde bulundurabilirsiniz. Yetkilendirme ara yazılımı bir geri dönüş ilkesi geçmeyi sağlar. Belirtilmişse geri dönüş ilkesi her ikisi için de geçerlidir:

• Belirtilen ilke olmayan uç noktalar.
• Uç noktayla eşleşmez istekler.

Bu, yetkilendirme ara yazılımlarını yönlendirme bağlamı dışında kullanışlı yapar. Yetkilendirme ara yazılımı, geleneksel ara yazılım programlaması için kullanılabilir.

Hata ayıklama tanılaması

Ayrıntılı yönlendirme tanılama çıktısı için, Logging:LogLevel:Microsoft olarak ayarlayın Debug . Geliştirme ortamında, appsettings.Development.jsüzerindeki günlük düzeyini ayarlayın:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Debug",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}