Qual è la suddivisione di tutti i layer richiesti/consigliati per un'applicazione Asp.Net Mvc seguendo le migliori pratiche di programmazione?

Question

Più leggo in Asp.Net MVC più strati e componenti sono necessari per far sì che la mia applicazione segua tutti gli standard e le migliori pratiche di programmazione.

Sta iniziando a diventare un po 'confuso perché alcuni dei nuovi livelli non sembrano adattarsi facilmente come gli altri che ho imparato. Quindi volevo solo che qualcuno superasse tutti i livelli richiesti/consigliati per un'applicazione ASP.Net MVC: quale scopo servono e come interagiscono con gli altri livelli.

Ecco alcuni degli strati che ho trovato e come si collegano: (Alcuni di essi possono essere sbagliato)

View/UI --> Model Binder --> Controller --> Service Layer --> Repository --> Entity Framework/LINQ to SQL --> DB 

Qualcuno potrebbe andare oltre quelli che potrebbero mancare, come tutti collegamento su, e quali sono i loro scopi?

Grazie,
Matt

Answer 1

Buona domanda, penso coperto tutti gli strati che ho visto: modale legante e livello di servizio sono opzionali.

Forse, è possibile aggiungere un altro livello di gestione degli errori come elmah.

• Visualizza/UI -> Hai inserito il codice markup/Javascript html.
• Raccoglitore modello -> Esegui la magia per associare il tuo input ai parametri di azione, normalmente, utilizzerai il raccoglitore predefinito, quindi non devi preoccuparti di questo. Tuttavia, puoi sovrascriverlo con il tuo raccoglitore e fare la convalida in questo livello. Ecco un good example su questo.
• Controller -> sufficiente documentazione online.
• Service Layer -> Molte persone eseguono la convalida e altre elaborazioni logiche di business qui prima di inviarle al repository. Asp.net mvc contact manger example ha un buon esempio qui. Questo è anche il livello per lavorare effettivamente con il tuo modal.
• Repository -> Operazione di lettura/scrittura semplice.
• Entity Framework/LINQ to SQL -> DB - Effettivamente la scrittura nel database. Nhibernate è un altro buon candidato qui.

Answer 2

Prima di tutto, penso che il software ed i modelli hanno la tendenza a complicare le cose. Come suggerisce il nome ASP, l'idea principale del framework è Model-View-Controller (MVC). Potresti essere in grado di mettere molte cose tra questi componenti, inclusi DB, servizi, API, ecc. Tuttavia, il concetto principale del modello Model-View-Controller è piuttosto semplice: separare queste funzionalità in moduli in modo che il progetto possa essere più facile da mantenere.

MVC può essere applicato a QUALSIASI programmazione o script che si faccia. Anche per uno script di shell MVC potrebbe essere utile. Ecco alcuni esempi di ciascuno:

• Visualizza - Ecco come l'utente interagisce. Potrebbe essere una pagina Web, Windows Form o un'interfaccia della riga di comando.
• Controller - Il cervello del programma, dovrebbe essere a conoscenza di tutto, ma dovrebbe essere piuttosto semplice. Prende fondamentalmente messaggi o eventi dalla vista e/o modello e decide su cosa fare. I buoni controller sono fondamentalmente un dispatcher di eventi. A seconda degli eventi, chiama i metodi view o model.In ASP MVC, il controller è quello che fornisce ActionResults per la vista e interagisce con il modello.
• Modello: questo è il punto in cui si trovano i dati. Questo potrebbe essere un DB, un file system, una sessione Web o una memoria.

Ora la parte buona. Al Controller non importa come la Vista gestisca l'interazione con l'utente. Potrebbe essere un'interfaccia a riga di comando o un modulo web. Il controller non sa come vengono memorizzati i dati, non importa se si tratta di un DB o di un file. Richiede solo dati e lo passa alla vista. Non è del suo business sapere come la vista sta ricevendo gli input, o il modello i dati.

Quindi la domanda, perché diavolo vogliamo complicare le cose con questo schema? Bene, immagina di avere un'applicazione MVC usando un DB MySQL e sappia che vuoi usare SQL Server. Quale modulo dovresti cambiare? Ovviamente il modello è quello colpito. Il controller e la vista non dovrebbero avere alcun impatto importante. Ora, immagina di avere un'altra applicazione MVC usando Windows Forms e ora vuoi cambiarla in Web Forms? Beh, in pratica, la Vista è quella che sarà interessata (e alcune parti del controller), ma il tuo Modello dovrebbe essere lo stesso.

In conclusione, MVC è un ottimo modello e dovrebbe essere utilizzato di più. Tuttavia, penso che ci siano alcuni progetti che non sono adatti per MVC a causa della sua semplicità. Sarà come costruire un laser per uccidere le mosche. Naturalmente li ucciderai, ma lo sforzo non è degno di tutti i casi.