Lato server C # MVC con AngularJS [duplicato]

Si può certamente usare qualsiasi combinazione di rendering lato client e rendering lato server, ma mi raccomando di provare a combinare gli helper MVC di ASP.NET con le direttive AngularJS. All'inizio potrebbe sembrare una buona idea perché sei già abituato a usare quegli helper e non devi scrivere "raw html", ma sconfiggono alcuni degli scopi di ciò che le applicazioni lato client cercano di ottenere: separazione delle preoccupazioni, reattività, associazione dei dati e testabilità.

C'è sicuramente spazio per realizzare mini-SPA all'interno di un'applicazione web più grande e tradizionale, soprattutto se si sta convertendo un'applicazione legacy o se parti della più grande applicazione non hanno bisogno di una SPA o sono meglio servite senza di essa. Ma se hai intenzione di rendere una determinata pagina - o parte di pagina - sul client, allora compra completamente e lascia che AngularJS faccia ciò che sa fare.

Quindi diciamo che hai un modello di prodotti (un elenco enumerabile di) e vuoi renderlo presente sulla pagina in un elenco. Hai tre opzioni a cui posso pensare:

1. Utilizzare un rasoio @ForEach e renderlo lato server, ma accettalo la tua applicazione AngularJS sul lato client non conoscerà questo elenco e non lo collegherà al suo modello
2. Attendi fino a quando la pagina viene caricata e AngularJS si avvia, quindi crea un'API chiamare l'applicazione MVC sul lato server per alcuni dati JSON e incollalo nel modello. Usa ng-repeat per visualizzare la lista.
3. Utilizzare il rasoio per serializzare il modello Prodotti sul server in alcuni Stringa JSON e incorporala nel controller AngularJS che hai inviato indietro. Usa ng-repeat per rendere l'elenco e sfruttare associazione dati lato client.

L'ultima opzione è brutta. Non riesco a pensare a una buona ragione per questo, a meno che non ti serva l'associazione dati lato client e devi pagare per ogni chiamata API.

Il primo sarebbe utile se non hai bisogno di alcun binding di dati sul client (è un elenco di sola lettura) o hai bisogno di SEO.

Il secondo è il modo in cui lo farei nella maggior parte degli scenari. Hai deciso di utilizzare AngularJS per un motivo: lascia che faccia il suo lavoro.

Non utilizzare gli helper MVC solo perché sono lì. AngularJS fornisce le proprie direttive che fanno più o meno le stesse cose. E se hai bisogno di più, scrivi il tuo. Parte dell'utilizzo di un framework lato client è l'acquisizione della filosofia: il server è responsabile di roba server-y come autenticazione, convalida del server e fornitura di dati tramite un'API, e il client è responsabile di essere un'applicazione front-end. Mantieni le tue preoccupazioni separate.

Questo non significa che non sia possibile utilizzare ASP.NET MVC per il routing, l'autenticazione o la struttura generale della tua app. Tutto ciò che circonda le tue app AngularJS. Una volta all'interno di una mini-SPA, però, fallo nel modo SPA.

Questa è la filosofia che ho usato durante l'integrazione di ASP.NET MVC con AngularJS. L'MVC lato server è responsabile esclusivamente del rendering della pagina iniziale e, successivamente, fornisce un'API semi-RESTful. Utilizza ASP.NET MVC per instradare URL, autenticare e altri extra. Ma non c'è quasi nessun rasoio e sicuramente nessun aiutante HTML.

Un po 'di un commento / risposta outsider, non sono un programmatore .NET MVC ma ho fatto un sacco di programmazione in PHP, Java e AS3 e relativamente recentemente sono passato a AngularJS.

La mia sensazione generale è che il back-end dovrebbe essere solo RESTful e non dovrebbe toccare realmente il front-end e il front-end dovrebbe dipendere solo dal back-end per i dati. Ci sono alcune eccezioni per quando sarebbe meglio creare viste sul lato server (forse per un'esportazione consistente per esempio o quando la memorizzazione nella cache delle viste aiuterà in modo significativo).

Il vantaggio della chiara linea di separazione sta permettendo ai tuoi team di lavorare in modo indipendente o se sei un one man shop per consentirti di concentrarti su un compito / problema alla volta (puoi eseguire il debug del back-end separatamente dal fronte -fine). Inoltre, se il progetto si espande e i client necessitano di una soluzione applicativa nativa, puoi comunque riutilizzare il tuo RESTful (il REST non è puramente necessario ma sembra la via da percorrere) back-end e semplicemente riscrivere il front-end.

Sto creando un'applicazione che è una combinazione di MVC sul server e AngularJS sul client.

Sul server:

Ho trovato che la cosa più semplice da fare era creare un gruppo di API web RESTful per fornire servizi dati al client. Inoltre eseguo la convalida sul server per assicurarmi che nessuno imbrogli (inviando i dati usando un client diverso dalla pagina web). Assemblerò anche la pagina Web (sebbene un controller e una vista minima) per caricare tutte le librerie di cui ha bisogno. Dal momento che sto costruendo la pagina web senza quasi modifiche dalla vista all'HTML finale, dovrei essere in grado di sostituire AngularJS con qualcos'altro.

Sul client:

Sul client, ho utilizzato AngularJS per gestire tutto, dalla chiamata della web API alla convalida locale. Dà all'utente la risposta "immediata" che viene spinta dall'ultima spinta sul web. Puoi rendere la tua pagina dinamica o relativamente statica. Usando un'architettura che usa una separazione di preoccupazioni, posso sostituire il back-end con qualsiasi cosa che supporti un'API RESTful.

Abbiamo creato un'app che è una combinazione di AngularJS e MVC

Le best practice dicono che mentre utilizziamo sia MVC che angularJS, dovremmo usare MVC web api sul lato server per ottenere dati dal server E sul lato client dovremmo usare il framework Angularjs per il binding dei dati JSON con i controlli html.

Sicuramente ... se si dispone di una SPA che descrive la pagina e richiede solo i dati forniti, è necessario un server RESTful che recuperi e restituisca i dati richiesti. Niente di più.

Se stai cercando di mescolare i due, allora penso che potresti rendere le cose molto complicate. Sicuramente l'utilizzo di MVC per generare le pagine iniziali è una buona idea, ma una volta fatto, si desidera comunque che le chiamate AngularJS effettuino richieste REST per i dati. La combinazione dei due sembra più semplice quando si tengono separate le 2 tecnologie.