MVC Pattern, ViewModels, Location of conversion

Sono d'accordo sul fatto che lo stai facendo nel modo giusto. Jimmy Bogard (autore di AutoMapper) ha scritto un eccellente articolo sul perché questo stile di struttura delle soluzioni funziona e seguo questa "guida" ogni volta che posso: link

Tuttavia, dovresti anche concentrarti su come ottenere la struttura giusta all'interno del tuo assieme di Library. Richard Dingwall ha scritto un articolo interessante sull'organizzazione del codice in base alla responsabilità piuttosto che alla tecnologia: link

Come ho capito la tua domanda, l'oggetto Entity è anche il tuo oggetto "dominio", cioè un oggetto che rappresenta un concetto di dominio. Questo oggetto non dovrebbe essere dettato da ciò che è necessario per essere visualizzato, ma come appare il tuo dominio. Questo tipo di logica si adatta perfettamente al progetto .Lib.

Quando dici che il controllore converte l'oggetto entità in un "modello", immagino che questo modello sia uno che contiene le proprietà che sono necessarie per essere visualizzate nella vista. Questo è anche chiamato "View Model" (si noti che le applicazioni WPF parlano anche di View Models, ma qui significano qualcosa di leggermente diverso).

Il punto è che il modello di vista in un'app ASP.NET MVC è un oggetto che comunica i dati tra il controller e la vista. E quella responsabilità non ha posto nel .Lib, appartiene solidamente nel .Web

Penso che lo stai facendo nel modo giusto.

Solo il controller dovrebbe ora ciò che esattamente ha bisogno di esso per riempire un modello con i dati di presentazione necessari. Per fare ciò mette insieme un gruppo di Entity Objects. L'esternalizzazione del compito di riempire i modelli su un altro livello sembra contraddire l'idea di una vista appartenente al livello di presentazione.

In realtà ho un'applicazione corrente impostata allo stesso modo ma con l'uso di servizi che restituiscono modelli e non oggetti EF. Il livello Web non conosce nulla di EF ma solo i modelli POCO definiti all'interno del livello lib. Quindi, il mio livello web non ha bisogno di un riferimento a EF per comprendere gli oggetti EF. Inoltre, faccio riferimento e utilizzo solo AutoMapper solo nel livello lib per convertire da oggetti EF ai miei modelli.

Ok, se hai classi generate da Entity Framework in qualsiasi punto vicino al tuo livello di servizio, non separerai le preoccupazioni correttamente.

Dai un'occhiata a EF POCO . Quello di cui hai veramente bisogno per mantenere separato il codice logico / DA / frontent (e quindi mantenibile) è il seguente setup (e un framework di iniezione di dipendenza decente):

• X.Web - Viste + logica di visualizzazione (elementi di formattazione ecc.)
• X.Interfacce - Definizioni dei tuoi servizi in forma di interfaccia
• X.Implementation - I tuoi servizi in forma di classe concreta
• X.DataModels - Definizioni degli oggetti dati e delle interfacce di accesso ai dati per ciascuno di essi
• X.DataAccess. "Inserisci il nome dello strumento DA qui" - questo è dove vanno le implementazioni delle tue interfacce di accesso ai dati.

In questo modo ti stai costringendo a tenere ogni serie di oggetti nascosti agli altri. Ad esempio, il livello di servizio dovrà conoscere il livello DA, ma non il modo in cui raggiunge effettivamente il suo DA, quindi ha solo bisogno di un riferimento esplicito all'assembly X.DataModels, dove risiedono i contratti di interfaccia per il livello DA.

Non vuoi davvero passare nulla del tuo specifico livello di accesso ai dati nel tuo servizio per un semplice motivo: cosa succede se cambi la metodologia DA?

Non sto parlando di un cambio di database qui: cosa succede se vuoi far scorrere uno strato di cache? Sarà molto più difficile se devi analizzare l'oggetto EF nel tuo livello di cache, poiché dovrai suddividere il codice di analisi in classi separate e condividerlo tra i livelli, che quindi lega strettamente i livelli Service e Cache. L'altra opzione sarebbe quella di mettere il livello di cache davanti al livello di servizio, tuttavia questo porterà altri problemi alla tabella (come i set di dati che vengono utilizzati ripetutamente in diversi servizi che vengono memorizzati nella cache in tempi leggermente diversi, il che può portare a tutti i tipi di nonesense).

Modifica

Sì, sono andato un po 'fuori pista in tutte le "lezioni EF di passaggio" su cosa. La conversione dall'oggetto dei dati alla vista dovrebbe essere fatta nel controller: sei completamente corretto su questo. Quanto sopra si applica comunque:)