Jak działa model serwerowego renderowania UI w Razor Pages i ASP.NET Core MVC?

W kontekście tworzenia dynamicznych interfejsów użytkownika przy użyciu Razor Pages oraz ASP.NET Core MVC, kluczowe jest zrozumienie, jak działa model serwerowego renderowania stron. W Razor Pages struktura aplikacji opiera się na stronach .cshtml oraz ich powiązanych klasach .cshtml.cs, gdzie umieszczamy logikę i właściwości potrzebne do interakcji z widokiem.

Przykładem jest dodanie do pliku Index.cshtml.cs właściwości Message, która będzie przechowywać tekst wyświetlany w interfejsie użytkownika. Aby zarządzać listą produktów, tworzymy w projekcie folder Models i definiujemy klasę Product z właściwościami Id, Name oraz Price. Następnie, w klasie IndexModel, dodajemy listę produktów (Products) oraz właściwość Color, która może określać kolor wyświetlania elementów w UI.

Ważnym elementem konwencji Razor Pages jest nazewnictwo metod obsługujących różne rodzaje żądań HTTP: OnGet, OnPost, OnDelete czy OnPut. Dzięki temu mechanizmowi framework automatycznie wywołuje odpowiednią metodę zależnie od typu żądania wysłanego przez klienta. Wiązanie parametrów z adresu URL lub formularza odbywa się przez mechanizm bindingu, który dopasowuje wartości do parametrów metody na podstawie nazw. W HTML-u wykorzystywana jest dyrektywa asp-route, która umożliwia przekazywanie parametrów do metody po stronie serwera, np. asp-route-id dla parametru id.

Model MVC dzięki wyraźnemu rozdzieleniu odpowiedzialności sprzyja stosowaniu dobrych praktyk programistycznych, takich jak testowanie jednostkowe, ponieważ logika biznesowa jest odseparowana od warstwy prezentacji i może być rozwijana niezależnie. Struktura projektu MVC jest nieco bardziej rozbudowana niż Razor Pages, jednak zapewnia większą elastyczność w zarządzaniu złożonymi aplikacjami.

Istotnym aspektem jest to, że oba podejścia — Razor Pages i MVC — opierają się na serwerowym generowaniu stron, co oznacza, że każde działanie użytkownika, które wymaga zmiany danych lub interakcji, powoduje wysłanie żądania do serwera. Serwer przetwarza dane, wykonuje logikę zawartą w modelu lub kontrolerze, a następnie zwraca do klienta nową, zaktualizowaną stronę HTML. To podejście różni się od nowoczesnych aplikacji SPA (Single Page Application), gdzie wiele operacji wykonuje się po stronie klienta.

Warto mieć na uwadze, że choć serwerowe renderowanie UI zapewnia dużą kontrolę nad procesem generowania strony oraz bezpieczeństwem, może wiązać się z większym obciążeniem serwera i koniecznością odświeżania całej strony przy każdej interakcji. W zależności od wymagań projektu i oczekiwanej responsywności aplikacji, decyzja o wyborze modelu (Razor Pages czy MVC) powinna uwzględniać specyfikę i skalę rozwiązania.

Jak zarejestrować middleware w ASP.NET Core 9 przy użyciu metod rozszerzeń?

W ASP.NET Core 9, jednym z kluczowych elementów umożliwiających elastyczne zarządzanie ruchem HTTP jest middleware. Ścisłe zarządzanie jego rejestracją może znacząco poprawić czytelność oraz ułatwić utrzymanie aplikacji, szczególnie w przypadku rozbudowanych projektów. Middleware w ASP.NET Core można rejestrować za pomocą metod rozszerzeń, co pozwala na centralizację konfiguracji oraz oddzielenie odpowiedzialności. W tym rozdziale przyjrzymy się, jak za pomocą tej techniki zorganizować rejestrację middleware w aplikacji ASP.NET Core 9.

W przypadku standardowych middleware dostarczanych przez ASP.NET Core 9, takich jak middleware do limitowania liczby zapytań, odpowiednie metody rozszerzeń są już dostępne. Jednak w przypadku tworzenia własnego middleware, każda niestandardowa funkcjonalność musi być zarejestrowana za pomocą metod rozszerzeń, takich jak UseMiddleware<>. Często spotykaną praktyką jest tworzenie oddzielnych metod rozszerzeń, które centralizują rejestrację różnych komponentów middleware, upraszczając kod i zapewniając większą modularność.

csharp
Copy code
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.AspNetCore.RateLimiting;
using System.Threading.RateLimiting;

public static class CommonMiddlewareExtensions

{
    public static IServiceCollection AddCustomRateLimiting(this IServiceCollection services)
    {
        services.AddRateLimiter(options =>
        {
            options.AddPolicy("fixed", context =>
                RateLimitPartition.GetFixedWindowLimiter(
                    new RateLimitPartitionKey(context.Request.Headers["X-Forwarded-For"].ToString(), PartitionKeyKind.ClientIP),
                    partition => new FixedWindowRateLimiterOptions
                    {
                        PermitLimit = 5,
                        Window = TimeSpan.FromMinutes(1),
                        QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                        QueueLimit = 2
                    }));
            options.AddPolicy("sliding", context =>
                RateLimitPartition.GetSlidingWindowLimiter(
                    new RateLimitPartitionKey(context.Request.Headers["X-Forwarded-For"].ToString(), PartitionKeyKind.ClientIP),
                    partition => new SlidingWindowRateLimiterOptions
                    {
                        PermitLimit = 5,
                        Window = TimeSpan.FromMinutes(1),
                        SegmentsPerWindow = 3,
                        QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                        QueueLimit = 2
                    }));
            options.AddPolicy("tokenBucket", context =>
                RateLimitPartition.GetTokenBucketLimiter(
                    new RateLimitPartitionKey(context.Request.Headers["X-Forwarded-For"].ToString(), PartitionKeyKind.ClientIP),
                    partition => new TokenBucketRateLimiterOptions
                    {
                        TokenLimit = 10,
                        TokensPerPeriod = 5,
                        ReplenishmentPeriod = TimeSpan.FromSeconds(10),
                        QueueProcessingOrder = QueueProcessingOrder.OldestFirst,
                        QueueLimit = 2
                    }));
        });
        return services;
    }
    public static void UseCommonApplicationMiddleware(this IApplicationBuilder app)
    {
        app.UseMiddleware<YourCustomMiddleware>();
        app.UseRateLimiter();
    }
}

Kolejnym krokiem jest zmiana pliku Program.cs, w którym rejestrujemy nasze metody rozszerzeń. Poniżej przedstawiamy kod, który włącza wszystkie wcześniej zdefiniowane middleware:

csharp
Copy code
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddCustomRateLimiting();
var app = builder.Build();
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
// Użycie niestandardowego middleware oraz limitowania zapytań
app.UseCommonApplicationMiddleware();
app.MapRazorPages();
app.Run();

Warto zauważyć, że stosowanie metod rozszerzeń przy rejestracji middleware jest dobrą praktyką, ponieważ umożliwia utrzymanie porządku w aplikacji, a także poprawia czytelność kodu. Ponadto, takie podejście pozwala na łatwiejsze zarządzanie i modyfikację poszczególnych elementów aplikacji w miarę jej rozwoju.

W kolejnych rozdziałach tej książki omówimy inne techniki, które pozwolą na jeszcze większą elastyczność aplikacji ASP.NET Core 9, takie jak zarządzanie konfiguracjami w sposób bezpieczny czy integracja z systemami zewnętrznymi.