ASP.NET Core 2.0 Razor vs Angular / React / ecc

101

Il mio team e io abbiamo ricevuto finanziamenti per iniziare a sviluppare un'applicazione web di livello Enterprise (non entreremo nei dettagli di ciò che fa). L'applicazione avrà molte pagine web separate, ma due di queste pagine saranno più mirate e molto pesanti - pesanti come in molte interazioni con l'utente, modali che visualizzano dati di massa, connessioni websocket, chat, ecc.

Sono stato assegnato a Chief Architect del progetto, quindi sto facendo delle ricerche sugli ultimi framework web. Per il back-end, abbiamo eseguito alcuni test e abbiamo deciso di utilizzare la piattaforma Azure SQL. Finora, mi piacciono i miglioramenti che sono stati apportati e vengono apportati a ASP.NET con Core 2.0. In particolare il motore Razor, rispetto alle versioni precedenti di ASP.NET MVC.

Volevo ottenere alcune opinioni di esperti sul "nuovo" Razor vs. Angular / React e simili. Sono particolarmente più interessato alle prestazioni. In che modo Core 2.0 Razor regge i framework di rendering lato client? Le differenze sono trascurabili? La nostra app si rivolge a un potenziale 1.000.000 di utenti (circa 100.000 simultanei).

Grazie in anticipo!

— TchPowDog
fonte

Con " new Razor " intendi le pagine Razor?

— Werner

Quindi quale hai scelto alla fine e come sta andando?

— stt106

Come sei andato (o stai andando avanti) con questo progetto? Sono in una situazione quasi identica alla tua ora e mi piacerebbe un aggiornamento!

— JLo

Ciao JLo e stt106. Mi dispiace che ci sia voluto così tanto tempo per rispondere. Abbiamo finito per optare per un front-end angolare e un backend per API ASP.NET Core, usando Azure SQL. Finora è andata benissimo per noi! Immagino che React sarebbe un sostituto simile ad Angular se ti sentissi più a tuo agio. Ho dovuto imparare Angular, che è stata una transizione molto facile, e ora lo adoro!

— TchPowDog

Il confronto tra la velocità di ASP.Net Core e Angular / React è fuori tema? Possono esserci risposte canoniche. Per quanto riguarda oggi abbiamo Core 2.2 e presto 3.0.

— MikroDel

Risposte:

Abbiamo finito per optare per un front-end angolare e un backend per API ASP.NET Core, usando Azure SQL. Abbiamo testato Core Razor e, sebbene migliore del precedente Razor, Angular è stato molto più veloce per noi alla fine. Per quanto riguarda l'esperienza utente, Angular (o React) è di gran lunga superiore in termini di prestazioni. Abbiamo scoperto che gli aspetti di associazione del modello di Angular sono un enorme vantaggio del rendering lato server. L'uso di Razor (o del rendering lato server in generale), tuttavia, si presta a una migliore integrità complessiva per quanto riguarda i dati e consente una migliore transizione dei dati dal front-end al back-end. Esiste una vera disconnessione tra un framework front-end e un'API. Tutti i dati che vengono passati al server devono essere inseriti in oggetti digitati - questo significa che devi gestire due set di modelli POCO separati. Ciò può causare problemi se gli oggetti server e gli oggetti front-end non si allineano. Al momento, Entity Framework Core non è molto maturo, quindi abbiamo problemi con l'aggiornamento di oggetti, l'esecuzione di query su oggetti, inclusi gli oggetti figlio, ecc.

Nel complesso, questa configurazione ha funzionato alla grande per noi finora! Immagino che React sarebbe un sostituto simile ad Angular se ti sentissi più a tuo agio. Ho dovuto imparare Angular, che è stata una transizione molto facile, e ora lo adoro!

— TchPowDog
fonte

Per quanto riguarda la sincronizzazione dei due set di modelli POCO, esiste un'estensione davvero utile per VS che crea interfacce angolari dai modelli MVC, controlla la macchina

— Andy Braham

beh, personalmente, se dovessi andare con Angular, userei NoSql per la parte DB.

— Venzentx

Non riesco a immaginare di selezionare il rasoio ASP.NET sopra Angular. In passato ASP.NET ha fornito un codice familiare per gli sviluppatori .NET, ma con RAZOR, la curva di apprendimento è più alta rispetto all'utilizzo di Angular. MVC divide la logica dall'HTML.

— Contrassegna il

@ Mark Non ci credo. Le pagine Razor sono perfette, in particolare il modo in cui gestiscono il data binding. Sono semplicemente troppo GOod. Ma ovviamente per il suo scenario angolare è perfettamente adatto.

— Mosia Thabo

@MosiaThabo, Mark non sta parlando di Razor Pages, sta parlando di Razor. Qual è ciò a cui si riferiva il mio OP. Nel mio post originale, non mi riferivo a Razor Pages (o ora chiamato Blazor, credo). Stavo parlando specificamente del rendering lato client rispetto al rendering lato server. Razor Pages è il gusto Microsoft di Angular / React, che penso ritengano necessario a causa dei vantaggi che hai con Angular e React.

— TchPowDog

Usando Angular / React con API sul lato server:

elimini il processo di generazione dell'HTML sul lato server e salvi la cpu
api produce un piccolo payload (json) e Razor (html) di un corso sarebbe di dimensioni molto più grandi, ricariche a pagina intera costanti e postback round trip. quindi api e spa risparmiano larghezza di banda
api e spa potrebbero avere diversi scenari di versioning, scaling e deployment
Utilizzando api puoi supportare anche l'app mobile e se inizi da Razor potresti aver bisogno di api in futuro

Ma usando Angular / React, dovresti essere preoccupato per i clienti:

il client deve abilitare javascript
il client deve disporre di browser moderni
il client deve disporre di hardware sufficientemente potente
SEO

— Mohsen Esmailpour
fonte

Capisco le differenze nei due framework, ero più interessato alle prestazioni.

— TchPowDog

La stessa pipline esiste per entrambi, ma non so che esista alcun benchmark per le pagine Razor. questo collegamento può aiutare - ASP.NET Razor Pages vs MVC: come si adattano le pagine Razor nella casella degli strumenti?

— Mohsen Esmailpour

Razor supporta i dispositivi mobili, gli svantaggi non contano davvero che sono elencati. Entrambi sono veloci a modo loro. Preferisco Angular, ma entrambi sono ottimizzati. Razor ottimizza il codice non utilizzando un albero come fa MVC. Angular è lato client, quindi non utilizza realmente un albero, ma ottimizza anche i dati nell'HTML in una certa misura.

— Nick Turner

@NickTurner Ho capito che non è solo la visualizzazione della pagina Web sul tuo smartphone, ma un'app completa. Ad esempio un'app Android, che potrebbe ottenere i dati dall'API del server invariata così com'è, mentre d'altra parte utilizzando le funzionalità fornite da Android - migliore supporto per animazioni, notifiche, messaggi di avviso, ecc.

— Raphael Schmitz

Non ho benchmark. Tuttavia, ho diversi progetti che eseguono JQuery, Razor, .NET MVC (C #), AJAX. Non alla scala che stai affrontando.

Consiglio .. Assicurati di riflettere sulle cose e di seguire le migliori pratiche. Per mantenere le cose mantenibili assicurati di rompere i controller, le visualizzazioni, il modello in gruppi più piccoli e significativi. Quando ho iniziato, ho commesso l'errore di mettere tutto in un controller Home e un sacco di visualizzazioni nella cartella condivisa. All'inizio andava bene, ma quando è iniziato il creep delle funzionalità, è diventato un disastro e difficile tornare indietro e riprogettare.

Uso anche Linq2SQL. Ho commesso l'errore di creare modelli per tutto e poi ho capito che potevo semplicemente restituire il set di risultati dalle mie query come modello. duh.

Se vai a .NET MVC e sei preoccupato per le prestazioni, queste sono le cose in cui mi sono imbattuto:

NON restituire visualizzazioni parziali che creano grandi blocchi di HTML! Assicurati di ridurre al minimo tutto. Sbarazzati di tutto lo spazio bianco. Usa nomi ID più piccoli. Prenditi il tempo per creare un html il più leggero possibile. Restituisci JSON e chiedi al cliente di eseguire parte del lavoro.

Fai attenzione a come sviluppi il tuo CSS. Non utilizzare un sacco di stili in linea, prenditi il tempo per incorporarli nei file CSS che puoi ridurre al minimo in seguito.

Lo stesso vale per il tuo JS lato client. Si è tentati di inserire il JS all'interno di viste parziali. Mantieni le cose organizzate.

Il rendering su IE è orribile. Soprattutto se ci sono molte immagini. Assicurati di comprimere le immagini il più possibile, senza perdere ovviamente la qualità.

— Keith Aymar
fonte