Come l'architettura ASP .NET MVC si adatta alla tradizionale architettura multilivello

Question

Passando dal tradizionale modo di progettare applicazioni Web con un livello aziendale, un livello di servizio, un livello di accesso ai dati e un livello di presentazione al modello di progettazione MVC, trovo difficile per capire come si adatta al vecchio modello.

Sembra che il modello MVC stesso abbia già fatto parte della separazione delle preoccupazioni che è necessaria e utilizzata per essere realizzata tramite un'architettura a più livelli. Qualcuno può far luce su questo argomento per favore?

Come riferimento, qui di seguito è come ho capito, si prega di condividere la sua opinione su questo

MVC viste e controllori insieme a visualizzare i modelli -are- Presentation Layer

MVC Modelli - potrebbe essere - di accesso ai dati di livello o business livello o addirittura Service layer

Answer 1

vedo la parte Asp.Net MVC solo come la parte vista (o presentazione) dell'intera applicazione.

Ho anche faticato con il problema su come strutturare l'app in modo corretto.
Dopo la Cipolla Architettura ho sentito parlare di here (e soprattutto l'immagine trovata here), la mia soluzione sembra in questo modo:

• Project.Core
  logica di business/servizi implementazioni, enti, interfacce che devono essere implementate dagli altri progetti (ad esempio "IRepository", "IAuthenticationService", ...)
• Project.Data
  Connessione DB: nel mio caso, repository NHibernate e mappature entità vanno qui. Implementa dati -interfaces di Project.Core
• Project.UI.Web
  L'Asp.Net MVC ("presentazione") del progetto - it fili tutta l'app insieme.
  Ha implementazioni per le interfacce in Project.Core e le collega (e quelle di Project.Data) con qualche framework DI come Castle Windsor.

Project.UI.Web segue le seguenti convenzioni: (!)

• suoi modelli sono solo ViewModels
• le vista consumare i loro propria viewmodel (one view-one-viewmodel)
• the controller solo nee d per validate l'ingresso, trasforma in oggetti del dominio (come la logica di business sa exacly nulla ViewModels) e delegato il vero lavoro (logica di business) per i servizi alle imprese.

Sommario:
Se si segue questo modello è utile focus sul progetto.Nucleo: che è l'applicazione reale. Non si preoccupa della reale persistenza dei dati né si preoccupa di come viene presentato. Si tratta solo di "come fare". Ma è la definizione delle regole e dei contratti (interfacce) per cui gli altri progetti devono fornire implementazioni.

Spero che questo ti aiuti con come impaginare un'applicazione Asp.Net MVC!

large
warappa

Answer 2

spiegazione molto semplice:

Se si crea una nuova applicazione MVC si otterrà automaticamente una cartella Controllers, Models and Views.

I suoi controllori agiscono come vostro livello di business
I modelli sono di accesso ai dati/strato di servizio
e Vista sono il livello di presentazione.

Vedere http://www.asp.net/mvc per una spiegazione dettagliata.

Answer 3

In breve: non cambia molto.

Ho solo familiarità con alcuni modelli di presentazione: MVP (Modello, Visualizza, Presenter, comune in Windows Form/asp.net), MVC (Modello, Visualizza, Controller) e MVVM (Modello, Visualizza, Visualizza modello , comunemente usato in WPF/Silverlight).

Link: http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx

link qui sopra dovrebbe rispondere ad alcune (se non tutti) delle vostre domande.

Il modo in cui solitamente scrivo le applicazioni ASP.NET MVC consiste nell'includere almeno un ibrido di livello Servizio/Business per le operazioni CRUD (poiché l'accesso ai dati non appartiene né al modello di vista né al controller e sicuramente non è nella vista!).

Answer 4

Come altri hanno già detto, non cambia molto. Le mie applicazioni sono tipicamente L'architettura dei in quanto tali:

• Modello a strati (dominio e visualizzare i modelli)
• Repository Layer (accesso ai dati)
• Servizio Layer (a volte implementato come servizi WCF a seconda delle app/requisiti)
• lato server MVC layer (Asp.net MVC stesso)
• lato client MVVM o MVC (tramite sia Knockout.js, Backbone.js o Spine.js)

Nel livello MVC lato server, i miei metodi di controllo sono molto chiari. In genere chiamano un metodo su un oggetto del livello di servizio per ottenere alcuni dati e passarli al client come dati Json.

Perché sto inviando Json, i miei punti di vista sono anche molto leggeri e sparsi. In genere contiene solo script inclusi e modelli che verranno renderizzati con una libreria di modelli lato client.