Se un livello di servizio Return modelli per un'applicazione MVC?

Question

Dire che hai un progetto ASP.NET MVC e utilizza un livello di servizio, come ad esempio in questo Contact Manager tutorial sul sito asp.net: http://www.asp.net/mvc/tutorials/iteration-4-make-the-application-loosely- accoppiata cs

Se avete ViewModels per le vostre opinioni, è il livello di servizio il luogo appropriato per fornire ad ogni ViewModel? Ad esempio, nell'esempio di codice livello di servizio v'è un metodo

    public IEnumerable<Contact> ListContacts()
    {
        return _repository.ListContacts();
    }

Se invece si voleva un IEnumerable, dovrebbe andare nel livello di servizio, o c'è qualche altra cosa che è il luogo "corretto"?

Forse in modo più appropriato, se si dispone di un ViewModel separato per ogni visualizzazione associata con ContactController, dovrebbe ContactManagerService avere un metodo separato per tornare ogni ViewModel? Se il livello di servizio non è il posto giusto, dove dovrebbe ViewModel oggetti essere inizializzati per l'utilizzo da parte del controllore?

Answer 1

In generale, no.

Visualizza i modelli hanno lo scopo di fornire informazioni da e verso punti di vista e dovrebbe essere specifico per l'applicazione, in contrapposizione al dominio generale. Controller devono orchestrare l'interazione con i repository, servizi (sto facendo alcune ipotesi della definizione di servizio qui), ecc e maniglia costruzione e validazione dei modelli di visualizzazione, e anche contenere la logica di determinare vista per il rendering.

Per fuoriuscita visualizzare i modelli in uno strato di "servizio", si stanno confondendo i livelli e ora hanno possibile specifica applicazione e la presentazione mescolato con quello che dovrebbe efficaci, con responsabilità a livello di dominio.

Answer 2

No, io non la penso così. I servizi dovrebbero preoccupano solo il dominio del problema, non la vista che rende i risultati. I valori di ritorno dovrebbero essere espressi in termini di oggetti di dominio, non viste.

Answer 3

Come per l'approccio tradizionale o teoria saggio, ViewModel dovrebbe essere parte dello strato di interfaccia utente. Almeno il nome dice così.

Ma quando si arriva ad attuare da soli con Entity Framework, MVC, Repository ecc, poi ti rendi conto qualcos'altro.

Qualcuno deve mappare modelle Entità / DB con ViewModels (DTO menzionato alla fine). Se questo dovesse essere fatto in [A] lo strato di interfaccia utente (dal controller), o in [B] Il livello di servizio?

I andare con l'opzione B. L'opzione A è un no no a causa del semplice fatto che diversi modelli di entità si combinano insieme per formare un ViewModel. Non possiamo passare i dati non necessari a livello di interfaccia utente, mentre in opzione B, il servizio può giocare con i dati e passare solo il / minimo richiesto per lo strato UI dopo la mappatura (al ViewModel).

Anche in questo caso, andiamo con l'opzione A, mettere ViewModel nello strato UI (e modello di entità nel livello di servizio).

Se le esigenze livello di servizio per mappare al ViewModel, poi lo strato di necessità di servizio per l'accesso ViewModel nello strato UI. Quale biblioteca / progetto? Il ViewModel dovrebbe essere in un progetto separato nel livello di interfaccia utente, e questo progetto ha bisogno di essere a cui fa riferimento servizio di livello. Se il ViewModel non è in un progetto separato, allora c'è riferimento circolare, quindi non andare. Sembra scomodo avere livello di servizio l'accesso a livello di interfaccia utente, ma ancora siamo riusciti a far fronte con essa.

Ma cosa succede se c'è un altro app UI Utilizzando questo servizio? Che cosa succede se c'è un app mobile? Quanto diverso può essere il ViewModel? Qualora il servizio di accesso allo stesso progetto vista del modello? Will tutti i progetti di interfaccia utente di accedere allo stesso progetto ViewModel o hanno la loro propria?

Dopo queste considerazioni la mia risposta sarebbe quella di mettere il progetto ViewModel in Service layer. Ogni strato di interfaccia utente deve accedere al livello di servizio in ogni modo! E ci potrebbe essere un sacco di ViewModels simili che tutti potrebbero usare (e quindi la mappatura diventa più facile per livello di servizio). Mapping vengono effettuate attraverso LINQ in questi giorni, che è un altro vantaggio.

Infine, c'è questa discussione su DTO. E anche di annotazione dei dati in ViewModel. ViewModels con annotazioni dati (Microsoft.Web.Mvc.DataAnnotations.dll) non possono risiedere in strato servizio invece risiedono nel livello UI (ma ComponentModel.DataAnnotations.dll possono risiedere in livello di servizio). Se tutti i progetti sono in un'unica soluzione (sln), quindi non importa quale livello si è messo. In applicazioni aziendali, ogni strato avrà una propria soluzione.

Quindi DTO in realtà è un ViewModel perché per lo più ci sarà uno contro uno mappatura tra i due (dire con automapper). Nuovo DTO ha ancora la logica necessaria per l'interfaccia utente (o più applicazioni) e risiede nel Service layer. E lo strato UI ViewModel (se usiamo Microsoft.Web.Mvc.DataAnnotations.dll) è solo per copiare i dati da DTO, con un po 'comportamento' / attributi aggiunti ad esso.

[Ora questa discussione è in procinto di prendere una piega interessante continuate a leggere ...: I]

E non credo che gli attributi dei dati di annotazione sono solo per l'interfaccia utente. Se si limita la convalida utilizzando System.ComponentModel.DataAnnotations.dll poi lo stesso ViewModel può essere utilizzato anche per front-end e back-end convalida (eliminando così UI-residente-ViewModel-copia-di-DTO). Inoltre attributi possono essere utilizzati anche in modelli di entità. Ad esempio: utilizzando .tt, modelli di dati Entity Framework possono essere generati automaticamente con la convalida degli attributi di fare alcune convalide di DB come max di lunghezza prima di inviare al back-end. Un altro vantaggio è che se la convalida backend cambia nel DB poi .tt (legge specifiche DB e creare l'attributo per la classe entità) prenderà automaticamente che fino. Questo può forzare UI unit test di validazione a fallire pure, che è un grande vantaggio (in modo che possiamo correggerlo ed informare tutti UI / consumatori, invece di dimenticare accidentalmente e non). Sì, la discussione si sta muovendo verso un disegno quadro buona. Come si può vedere è tutto correlato:. Tier-saggio di convalida, la strategia di test di unità, strategia di cache, ecc

Anche se non direttamente correlata alla question. 'ViewModel Façade' menzionato in questo deve guardare canale 9 di collegamento è anche la pena di esplorare. Si inizia esattamente a 11 minuti 49 secondi nel video. Perché questo sarebbe il prossimo passo / pensato una volta che la domanda corrente di cui sopra viene risolto: 'Come organizzare ViewModels?'

Anche nel tuo esempio "_repository.ListContacts ()" è la restituzione di un ViewModel dal repository. Questo non è un modo maturo. Repository dovrebbero fornire modelli di entità o modelli DB. Questo viene convertito in modelli vista ed è questo modello di vista che viene restituito dal livello di servizio.

Answer 4

suppongo che dipende da ciò che si considera i "servizi" di essere. Non ho mai piaciuto il termine servizio , nel contesto di una singola classe; è incredibilmente vago e non dice molto circa lo scopo effettivo della classe.

Se il "livello di servizio" è uno strato fisico, come ad esempio un servizio Web, quindi assolutamente no; servizi in un contesto SOA devono esporre le operazioni di dominio / affari, non i dati e non la logica di presentazione. Ma se servizio è solo di essere utilizzato come un concetto astratto per un ulteriore livello di incapsulamento, non vedo alcun problema con l'utilizzo nel modo che desribe.

Basta non mescolare i concetti. Se i vostri offerte di servizi con modelli di vista, allora dovrebbe essere un servizio di presentazione e di essere a strati sopra la parte superiore del reale Modello, toccare mai direttamente il database o qualsiasi logica di business.

Answer 5

Questa è venuto un po 'di un "dipende" dove lavoro - abbiamo generalmente avuto un controllore consumatore qualche servizio (s) - allora la combinazione restituita DTO in un 'ViewModel' che sarebbe poi ottenere passati al cliente - sia tramite risultato JSON, o legati al modello di rasoio.

Il fatto è che circa l'80% del tempo - la mappatura delle DTO al ViewModel è stato 1-1. Stiamo iniziando a muoversi verso 'Dove necessario, basta consumare direttamente il DTO, ma quando il DTO e che cosa abbiamo bisogno nel nostro client / vista non corrispondono - viene creato un ViewModel e fare il mapping tra gli oggetti, se necessario'.

Anche se sono ancora convinto che questa sia la soluzione migliore o di destra - '? Stiamo semplicemente aggiungendo X per il DTO per soddisfare le esigenze della vista' come va a finire che conduce ad alcune accese discussioni su