19 messaggi dal 14 gennaio 2008
Ottimo articolo! Quello che non avete spiegato però è la seguente cosa: se io inizio adesso un progetto nuovo con Blazor e tra un anno (non so il termine temporale) uscirà finalmente la parte client con WebAssembly, il passaggio tra quella server e quella client, averà in maniera indolore cambiando poche cose, o sarà un bagno di sangue?
Grazie
181 messaggi dal 10 agosto 2019
articolo molto interessante,spannometricamente quando uscirà BlazorWebAssembly? ,grazie
1.509 messaggi dal 27 dicembre 2005
Spero avrà seguito questo proggetto!
se strutturi bene i componenti quasi indolore, ClassLibrary condivisa tra progetto Server e Client, i quali avranno le loro differenze per autenticazione e nello startup.cs

WebAssembly si parla di Maggio 2020 ... e poi seguiranno PWA, Electron, etc...

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-
totti240282 ha scritto:
Spero avrà seguito questo proggetto!


Se non lo cancellano è già dentro .net core 3.0 la parte server e client webassembly maggio 2020

Non hai veramente capito qualcosa fino a quando non sei in grado di spiegarlo a tua nonna.
-Albert Einstein-
11.886 messaggi dal 09 febbraio 2002
Contributi

Ottimo articolo! Quello che non avete spiegato però è la seguente cosa: se io inizio adesso un progetto nuovo con Blazor e tra un anno (non so il termine temporale) uscirà finalmente la parte client con WebAssembly, il passaggio tra quella server e quella client, averà in maniera indolore cambiando poche cose, o sarà un bagno di sangue?

Ciao, grazie!
Dipende da come strutturi l'applicazione. Se nel blocco @code usi Entity Framework Core per leggere i dati dal database, poi quel codice non potrà funzionare una volta che ti sposti su Blazor WebAssembly, perché il database non sarà direttamente accessibile dal client. Dovrai invece fare affidamento sull'oggetto HttpClient in modo da inviare una richiesta ad una Web API.
Se hai tanti Razor Component, dovrai fare parecchie modifiche.

Un'alternativa migliore potrebbe essere quella di astrarre dall'effettiva tecnica usata per recuperare i dati, in modo che nel Razor Component non ci sia traccia né di EFCore né di HttpClient. Supponiamo che il tuo Razor Component sia scritto così:
@page "/products"
@inject IProductService productService

<h1>Prodotti</h1>
<table>
@foreach (var product in products)
{
 //...
}
</table>

@code {
    ProductDto[] products;

    protected override async Task OnInitializedAsync()
    {
        products = await productService.GetAllAsync();
    }
}

Come vedi, io sto recuperando i prodotti sfruttando un servizio che implementa IProductService. In questo modo il Razor Component resta completamente agnostico del codice infrastrutturale che serve a recuperare i prodotti. Fintanto che sei su Blazor Server, la dipendenza da IProductService verrà risolta con una implementazione concreta che internamente sfrutta EfCore.
Nel momento invece in cui vai su WebAssembly, dovrai scrivere un'altra implementazione concreta che si avvale di HttpClient. Quindi un po' di lavoro andrà comunque fatto.
Qui c'è un link per approfondire la questione della dependency injection in Blazor WebAssembly.
https://docs.microsoft.com/it-it/aspnet/core/blazor/dependency-injection?view=aspnetcore-3.0

Ciao e di nuovo grazie!
Moreno

Enjoy learning and just keep making
Script su questo argomento molto presto :)
311 messaggi dal 08 gennaio 2011
Grande Moreno !
A parte tutto il discorso su Blazor che mi interessa meno dato che è un ennesimo framework che richiede sempre una nuova fase di apprendimento per fare sempre le stesse cose, ciò che mi ha fatto rizzare i 4 peli che mi sono rimasti sulla testa è il contenuto del link ai WebAssembly ! Forse si va finalmente verso una vera piattaforma comune, universale. Viva il W3C. :-)))

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.