Blazor of MVC en Razor Pages voor een interne bedrijfsapplicatie?

Een .NET-team gaat een interne applicatie bouwen: orders, goedkeuringen, rapporten. De helft van het team kent ASP.NET MVC of Razor Pages door en door, en beide zijn beproefd, stabiel en goed gedocumenteerd. Iemand stelt Blazor voor. Is dat de moeite waard?

Microsofts eigen gids voor het kiezen van een web-UI is duidelijk: Blazor wordt aanbevolen voor de meeste web-UI-scenario’s. Maar dat betekent niet dat elke MVC-applicatie herschreven moet worden. De echte vragen zijn hoe interactief de schermen zijn, en wat u al hebt.

Het verschil in drie zinnen

• MVC: controllers ontvangen het verzoek, bereiden de gegevens voor en geven een view terug. Elke klik die de server nodig heeft, is een nieuw verzoek.
• Razor Pages: hetzelfde idee, georganiseerd per pagina in plaats van per controller. Eenvoudiger voor applicaties met veel formulieren.
• Blazor: het scherm bestaat uit C#-componenten. Die kunnen op de server worden gerenderd zoals Razor Pages, of interactief draaien, op de server of in de browser via WebAssembly.

Hetzelfde formulier in beide

Een eenvoudig formulier voor een nieuwe order. In Razor Pages de pagina en de handler:

@page
@model NewOrderModel

<form method="post">
    <input asp-for="Order.Customer" />
    <span asp-validation-for="Order.Customer"></span>
    <button>Save</button>
</form>

public class NewOrderModel(OrderService orders) : PageModel
{
    [BindProperty]
    public OrderInput Order { get; set; } = new();

    public async Task<IActionResult> OnPostAsync()
    {
        if (!ModelState.IsValid)
            return Page();

        await orders.CreateAsync(Order);
        return RedirectToPage("Index");
    }
}

In Blazor één component:

@inject OrderService Orders
@inject NavigationManager Navigation

<EditForm Model="Order" OnValidSubmit="SaveAsync" FormName="new-order">
    <DataAnnotationsValidator />
    <InputText @bind-Value="Order.Customer" />
    <ValidationMessage For="() => Order.Customer" />
    <button>Save</button>
</EditForm>

@code {
    [SupplyParameterFromForm]
    private OrderInput? Order { get; set; }

    protected override void OnInitialized() => Order ??= new();

    private async Task SaveAsync()
    {
        await Orders.CreateAsync(Order!);
        Navigation.NavigateTo("/orders");
    }
}

Voor een eenvoudig formulier is het ongeveer evenveel werk. Het verschil verschijnt zodra het scherm moet reageren: de prijs wordt herberekend als het aantal verandert, de tweede keuzelijst hangt af van de eerste, de lijst filtert terwijl u typt. In MVC en Razor Pages is dat JavaScript naast de C#. In Blazor blijft het in C#, in hetzelfde component.

Vergeleken op wat telt voor het bedrijf

	Blazor	MVC en Razor Pages
Interactieve schermen	In C#, zonder aparte JavaScript	JavaScript, of een bibliotheek zoals htmx, naast de C#
Eenvoudige formulieren en lijsten	Even eenvoudig	Even eenvoudig, en zeer volwassen
Herbruikbare delen van het scherm	Componenten, in de hele applicatie	Partial views en tag helpers, minder natuurlijk
Publieke pagina’s en SEO	Goed met statische server-rendering	Uitstekend, een natuurlijke fit
Serverresources	De interactieve servermodus houdt een verbinding per open browsertabblad	Een verzoek, een antwoord, niets blijft bewaard
Het team	C#-developers zijn snel productief	De meeste .NET-developers kennen het al
Bestaande applicatie	Kan scherm voor scherm worden aangevuld	Blijft zoals ze is

De serverrij verdient een zin. Blazor in interactieve servermodus houdt voor elk open tabblad een live verbinding. Voor een interne applicatie met een paar honderd gebruikers is dat geen probleem. Voor een publieke site met duizenden bezoekers gebruikt u voor die pagina’s statische rendering of WebAssembly. Wanneer u wat gebruikt, leest u in ons artikel over Blazor Server of WebAssembly.

Wanneer MVC of Razor Pages de juiste keuze blijft

• Er draait al een grote MVC-applicatie. Die herschrijven alleen om van framework te wisselen loont zelden.
• Vooral formulieren en statische pagina’s, met weinig interactie op het scherm.
• Publieke content die snel moet laden en moet scoren in Google.
• Een team dat MVC goed kent en geen rijkere schermen nodig heeft.

U hoeft zelden maar één te kiezen

Blazor-componenten kunnen binnen een bestaande MVC- of Razor Pages-applicatie leven. Daarom is de veiligste route een geleidelijke: de bestaande schermen blijven zoals ze zijn, en nieuwe, interactievere schermen worden in Blazor geschreven. Zo verandert de applicatie in het tempo dat het bedrijf nodig heeft, zonder grote herschrijving. Dezelfde aanpak werkt voor oudere applicaties; zie ons artikel over Web Forms naar Blazor.

Vijf vragen voor u beslist

1. Hoeveel van de applicatie bestaat uit formulieren en lijsten, en hoeveel uit schermen die reageren terwijl u werkt?
2. Is er al een MVC- of Razor Pages-applicatie, en werkt die?
3. Is de applicatie intern of achter een login, of publiek en afhankelijk van Google?
4. Hoeveel gebruikers hebben haar tegelijk open?
5. Wie onderhoudt haar over vijf jaar, en wat kunnen die mensen?

Wijzen de antwoorden naar interactieve schermen, een login en een C#-team, kies dan Blazor voor het nieuwe werk. Wijzen ze naar een werkende MVC-applicatie met vooral formulieren, houd die dan en voeg Blazor alleen toe waar een scherm het echt nodig heeft. Hoe Blazor zich verhoudt tot de JavaScript-frameworks, leest u in Blazor of Angular en Blazor of React.

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië. We onderhouden MVC- en Razor Pages-applicaties en brengen Blazor sinds 2020 in productie, dus we hebben geen reden om het een boven het ander te pushen. We helpen u kiezen, bouwen nieuwe Blazor-applicaties en brengen Blazor scherm voor scherm in bestaande applicaties. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• Choose an ASP.NET Core web UI, Microsoft Learn
• ASP.NET Core Blazor render modes, Microsoft Learn
• Integrate ASP.NET Core Razor components into ASP.NET Core apps, Microsoft Learn