La lliçó anterior va exposar el domini de BiblioTech com una API HTTP amb ASP.NET Core, pensada perquè qualsevol client la consumeixi —inclòs un client escrit en JavaScript, l'opció tradicional per construir interfícies web—. Blazor proposa una altra via: construir aquesta interfície web amb C#, reutilitzant el mateix llenguatge i bona part de les idees de components i data binding ja vistes a WPF, però executant-se en el context d'un navegador. Aquesta lliçó explica els dos models d'execució de Blazor (Server i WebAssembly), la sintaxi d'un component .razor, i construeix un component Cataleg.razor que llista el catàleg de BiblioTech i injecta Biblioteca directament com a servei, sense passar per peticions HTTP manuals.

1. Què és Blazor: C# també al navegador
2. Els dos models: Blazor Server davant Blazor WebAssembly
3. Components .razor: estructura bàsica
4. Sintaxi de Razor: @code, @bind, @onclick
5. Cicle de vida d'un component: OnInitializedAsync
6. Injecció de dependències en un component: @inject
7. Exemple complet: Cataleg.razor per a BiblioTech
8. Quan triar Blazor davant ASP.NET Core "pur" o davant WPF

Tradicionalment, la interfície d'una aplicació web es construeix amb HTML, CSS i JavaScript, mentre que el servidor (per exemple, amb ASP.NET Core, lliçó anterior) es limita a servir dades. Blazor trenca aquesta frontera: permet escriure la interfície web en C#, organitzada en components reutilitzables (fitxers .razor), sense necessitat d'escriure JavaScript per a la lògica de la interfície.

La conseqüència pràctica més important: tot el que ja saps de C# —classes, LINQ, async/await, el mateix domini de BiblioTech— es pot fer servir directament al navegador, sense traduir-lo a cap altre llenguatge ni exposar-lo primer com a API JSON, com sí que caldria amb un frontend tradicional en JavaScript.

Blazor ofereix dues formes diferents d'executar aquest mateix codi C#, amb implicacions molt diferents sobre on viu realment la lògica:

Per a BiblioTech, Blazor Server encaixa millor amb l'exemple d'aquesta lliçó: el component Cataleg.razor pot injectar Biblioteca directament com a servei del servidor (igual que un endpoint d'ASP.NET Core), sense passar per HTTP; Blazor WebAssembly, en canvi, obligaria a consumir l'API construïda a la lliçó anterior mitjançant HttpClient (Mòdul 5), perquè el codi C# del component s'executaria al navegador de l'usuari, sense accés directe al servidor ni a la seva base de dades.

Un component Blazor combina marcatge de tipus HTML amb codi C#, en un mateix fitxer .razor:

La barreja d'HTML i C# dins del mateix fitxer recorda la separació XAML/code-behind de WPF, però amb una diferència notable: a Blazor, el marcatge i el codi C# conviuen en un únic fitxer .razor, en lloc de repartir-se entre un .xaml i un .xaml.cs separats.

Dins del marcatge, qualsevol expressió C# s'introdueix amb @:

Per al data binding d'un camp de formulari, @bind connecta el valor d'un control amb una propietat C#, d'una manera semblant al {Binding ...} de WPF però amb sintaxi pròpia de Razor:

Per gestionar esdeveniments, @onclick (i equivalents com @onchange, @onsubmit) connecta un esdeveniment del DOM amb un mètode C#, sense necessitat de JavaScript:

Després de qualsevol esdeveniment gestionat per Blazor (@onclick, @bind...), el framework torna a renderitzar automàticament la part del component que hagi canviat —d'una manera conceptualment semblant a com WPF actualitza la vista en disparar PropertyChanged, encara que el mecanisme intern de Blazor sigui diferent (compara l'arbre de marcatge abans i després de l'esdeveniment, i actualitza només les diferències).

Un component Blazor passa per una sèrie de mètodes de cicle de vida, invocats automàticament pel framework en moments concrets. El més habitual per carregar dades en mostrar el component és OnInitializedAsync:

OnInitializedAsync és el lloc habitual per carregar dades inicials —d'una base de dades, d'una API, o, com a l'apartat 7, directament d'un servei injectat—, d'una forma equivalent a com el constructor de CatalegViewModel a WPF preparava Cataleg abans de mostrar la finestra. La diferència és que aquí és un mètode async, pensat per esperar operacions que trigin (com una consulta a base de dades) sense bloquejar la càrrega inicial de la pàgina.

Un component Blazor pot rebre serveis registrats al contenidor de dependències (el mateix mecanisme vist a la lliçó d'ASP.NET Core) amb la directiva @inject:

@inject Biblioteca Biblioteca resol una instància de Biblioteca des del contenidor de serveis (registrada a Program.cs amb builder.Services.AddSingleton<Biblioteca>(), igual que a la lliçó anterior) i l'exposa com una propietat disponible a tot el component, sense necessitat de rebre-la per paràmetre ni construir-la manualment. Com s'ha indicat a la introducció del mòdul, la injecció de dependències com a mecanisme general s'estudia en profunditat al Mòdul 8; aquí n'hi ha prou amb reconèixer que @inject és, per a un component Blazor, l'equivalent a rebre un paràmetre ja resolt en un endpoint d'ASP.NET Core.

Unint totes les peces anteriors, un component que llista el catàleg i permet prestar cada llibre amb un botó, fent servir Blazor Server i injectant Biblioteca directament:

@onclick="() => PrestarMaterial(material)" fa servir una expressió lambda (Mòdul 4) per passar el material concret de cada fila a PrestarMaterial, una cosa necessària perquè @foreach genera una fila per element i cada botó ha d'actuar sobre el seu propi material, no sobre un de fix. disabled="@(!material.Disponible)" desactiva el botó quan el material ja està prestat, sense necessitat de cap codi addicional: Razor avalua l'expressió C# entre parèntesis i l'assigna a l'atribut HTML disabled. Igual que a WPF, cap fragment d'aquest component reimplementa la comprovació de disponibilitat: es recolza completament en material.Prestar(), que ja la resol des del Mòdul 2.

Blazor no substitueix ASP.NET Core: de fet, un projecte Blazor Server s'executa sobre ASP.NET Core (fa servir Kestrel i el mateix contenidor de serveis per sota); la diferència és que Blazor afegeix, a sobre, un model de components amb interfície visual, mentre que la Minimal API de la lliçó anterior es queda només a la capa de dades, sense interfície pròpia.

• Confondre Blazor Server amb Blazor WebAssembly en decidir com accedir a les dades: a Blazor Server, injectar Biblioteca directament (com a l'apartat 7) és correcte i eficient; a Blazor WebAssembly, el mateix enfocament no funcionaria, perquè el component s'executa al navegador del client, sense accés directe al servidor —caldria HttpClient contra l'API de l'apartat anterior.
• Oblidar disabled="@(!material.Disponible)" o una comprovació equivalent: sense ella, l'usuari podria fer clic a "Prestar" sobre un material ja prestat; el mètode PrestarMaterial ho detecta igualment (per la comprovació de Disponible), però desactivar el botó millora l'experiència evitant l'intent en primer lloc.
• Escriure lògica de negoci directament al marcatge Razor en lloc de en un mètode del bloc @code: dificulta la lectura i la prova del component; la regla pràctica és la mateixa que a WPF, mantenir el marcatge declaratiu i la lògica al codi.
• Consell: Blazor Server manté una connexió persistent (SignalR) amb cada usuari connectat; en una aplicació amb moltíssims usuaris simultanis, això consumeix més recursos del servidor que Blazor WebAssembly, on cada navegador executa la seva pròpia còpia del codi —una consideració d'escalabilitat a tenir en compte en triar el model.

1. Afegeix a Cataleg.razor un <input @bind="textCerca" /> i filtra la taula mostrada perquè només hi apareguin els materials el Titol dels quals contingui el text introduït (fes servir Contains, ja vist al Mòdul 1, i actualitza el filtre a cada pulsació mitjançant @bind:event="oninput").

2. Afegeix un comptador <p>Total disponibles: @Biblioteca.Cataleg.Count(m => m.Disponible)</p> a sobre de la taula, i explica en un comentari per què no cal cap codi addicional perquè s'actualitzi després de cada préstec.

<input @bind="textCerca" @bind:event="oninput" placeholder="Cercar per titol..." />

<table>
    <tbody>
        @foreach (MaterialBibliotecari material in Biblioteca.Cataleg.Where(
            m => m.Titol.Contains(textCerca, StringComparison.OrdinalIgnoreCase)))
        {
            <tr>
                <td>@material.Titol</td>
                <td>@material.Autor</td>
            </tr>
        }
    </tbody>
</table>

@code {
    private string textCerca = string.Empty;
    // ... resta del codi existent ...
}

<p>Total disponibles: @Biblioteca.Cataleg.Count(m => m.Disponible)</p>

@* No cal codi addicional perque Blazor torna a renderitzar el component sencer
   despres de cada esdeveniment gestionat (com el @onclick de PrestarMaterial); en renderitzar
   de nou, aquesta expressio es reavalua automaticament contra l'estat actual de
   Biblioteca.Cataleg, sense necessitat d'actualitzar manualment cap variable. *@

En aquesta lliçó has vist com Blazor porta C# al navegador, amb dos models d'execució —Server i WebAssembly— que canvien completament on viu la lògica i com s'accedeix a les dades, components .razor que combinen marcatge i codi, @bind/@onclick per a la interacció, i @inject per obtenir serveis del contenidor de dependències. El component Cataleg.razor reutilitza, una vegada més, el mateix Biblioteca.Cataleg i el mateix material.Prestar() vistos des del Mòdul 2, ara accessibles des de qualsevol navegador.

L'última lliçó d'aquest mòdul presenta Xamarin i .NET MAUI, que porten BiblioTech a dispositius mòbils i d'escriptori amb un únic projecte multiplataforma, fent servir un XAML molt semblant al de WPF —tancant així el recorregut per les principals formes de construir interfícies en C#, abans que el Mòdul 8 poleixi el codi de tot el que s'ha construït amb bones pràctiques i patrons de disseny.