Blazor eller MVC och Razor Pages för en intern affärsapplikation?

Ett .NET-team ska bygga en intern applikation: order, godkännanden, rapporter. Halva teamet kan ASP.NET MVC eller Razor Pages utan och innan, och båda är beprövade, stabila och väldokumenterade. Någon föreslår Blazor i stället. Är det värt det?

Microsofts egen guide för att välja webbgränssnitt är tydlig: Blazor rekommenderas för de flesta webbscenarier. Men det betyder inte att varje MVC-applikation ska skrivas om. De verkliga frågorna är hur interaktiva vyerna är, och vad du redan har.

Skillnaden i tre meningar

• MVC: controllers tar emot förfrågan, förbereder data och returnerar en vy. Varje klick som behöver servern är en ny förfrågan.
• Razor Pages: samma idé, organiserad per sida i stället för per controller. Enklare för formulärtunga applikationer.
• Blazor: vyn byggs av C#-komponenter. De kan renderas på servern som Razor Pages, eller köras interaktivt, på servern eller i webbläsaren via WebAssembly.

Samma formulär i båda

Ett enkelt formulär för en ny order. I Razor Pages sidan och dess 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");
    }
}

I Blazor en enda komponent:

@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");
    }
}

För ett enkelt formulär är det ungefär lika mycket arbete. Skillnaden syns så fort vyn måste reagera: priset räknas om när antalet ändras, den andra listrutan beror på den första, listan filtreras medan du skriver. I MVC och Razor Pages är det JavaScript bredvid C#. I Blazor stannar det i C#, i samma komponent.

Jämfört efter det som spelar roll för verksamheten

	Blazor	MVC och Razor Pages
Interaktiva vyer	I C#, utan separat JavaScript	JavaScript, eller ett bibliotek som htmx, bredvid C#
Enkla formulär och listor	Lika enkelt	Lika enkelt, och mycket moget
Återanvändbara delar av vyn	Komponenter, i hela applikationen	Partial views och tag helpers, mindre naturligt
Publika sidor och SEO	Bra med statisk serverrendering	Utmärkt, helt naturligt
Serverresurser	Interaktivt serverläge håller en anslutning per öppen flik	En förfrågan, ett svar, inget sparas
Teamet	C#-utvecklare blir snabbt produktiva	De flesta .NET-utvecklare kan det redan
Befintlig applikation	Kan kompletteras vy för vy	Förblir som den är

Serverraden förtjänar en mening. Blazor i interaktivt serverläge håller en levande anslutning för varje öppen flik. För en intern applikation med några hundra användare är det inget problem. För en publik webbplats med tusentals besökare använder du statisk rendering eller WebAssembly för de sidorna. När du ska välja vad går vi igenom i artikeln om Blazor Server eller WebAssembly.

När MVC eller Razor Pages förblir rätt val

• En stor MVC-applikation fungerar redan. Att skriva om den bara för att byta ramverk lönar sig sällan.
• Mest formulär och statiska sidor, med lite interaktion i vyerna.
• Publikt innehåll som måste laddas snabbt och synas på Google.
• Ett team som kan MVC väl och inte behöver rikare vyer.

Du behöver sällan välja bara ett

Blazor-komponenter kan leva inuti en befintlig MVC- eller Razor Pages-applikation. Därför är den säkraste vägen stegvis: de befintliga vyerna förblir som de är, och nya, mer interaktiva vyer skrivs i Blazor. Applikationen förändras då i den takt verksamheten behöver, utan en stor omskrivning. Samma angreppssätt fungerar för äldre applikationer; se artikeln om Web Forms till Blazor.

Fem frågor innan du bestämmer dig

1. Hur mycket av applikationen är formulär och listor, och hur mycket är vyer som reagerar medan du arbetar?
2. Finns det redan en MVC- eller Razor Pages-applikation, och fungerar den?
3. Är applikationen intern eller bakom inloggning, eller publik och beroende av Google?
4. Hur många användare har den öppen samtidigt?
5. Vem förvaltar den om fem år, och vad kan de?

Pekar svaren mot interaktiva vyer, inloggning och ett C#-team, välj Blazor för det nya arbetet. Pekar de mot en fungerande MVC-applikation med mest formulär, behåll den och lägg till Blazor bara där en vy verkligen behöver det. Hur Blazor står sig mot JavaScript-ramverken läser du i Blazor eller Angular och Blazor eller React.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien. Vi förvaltar MVC- och Razor Pages-applikationer och har levererat Blazor i produktion sedan 2020, så vi har ingen anledning att driva det ena framför det andra. Vi hjälper dig att välja, bygger nya Blazor-applikationer och för in Blazor i befintliga applikationer vy för vy. Första steget: Boka ett kostnadsfritt samtal på 30 minuter.

Källor

• 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