Definizione corretta e progettazione di modelli di business, dominio e visualizza in un'applicazione a strati MVC

Question

Ho un ASP.NET MVC3 in C# e Razor. L'architettura dell'applicazione è divisa nel livello di accesso ai dati (Classi EF + repository), livello di servizio, controller, ViewModels e View.

La mia applicazione è un Pannello, deve visualizzare statistiche sui prodotti utilizzando i grafici.

Supponiamo di averlo Product e ProductCategory tabelle e in un grafico devo visualizzare la percentuale di venduta Products per ProductCategory per Mese. Nell'asse X ho i mesi, nell'asse y la percentuale ProductPerCategory/ProductTotal E quindi ho tutte le righe che ProductCategories.

In questo caso il mio Modello di dominio è realizzato da Product e ProductCategory oggetti sul Ef. Il mio repository dà questi Oggetti di dominio al suo livello superiore (livello di servizio).

Mio Modello di business è realizzato dal ProductGraph oggetto e mio Livello di servizio Fornisce questo oggetto aziendale al suo livello superiore (controller).

Il mio controller prende questo ProductGraphoggetto e mapparlo a Visualizza modello ProductGraphViewModel da visualizzare nella vista.

Questa distinzione tra i modelli è corretta? Esiste un approccio carente o cattivo sulla definizione degli oggetti passati tra i livelli?

Answer 1

Risponderò alla tua domanda facendo alcuni dei miei.

1. Qual è la tua distinzione tra "modello di dominio" e "modello di business"? Ognuno dà più valore/meno rispetto all'altro? Senza saperne di più, suppongo che siano la stessa cosa.

2. Che vantaggio offre il tuo livello di servizio? Le persone (me compreso) sono spesso cadute nella trappola del "livello di servizio", quando in realtà avvolge i tuoi metodi di repository. Finisci per perdere specifiche ORM per consumare strati, sconfiggendo il punto della tua astrazione in primo luogo.

Potrebbe aiutarci se ci dai un po 'di codice di un flusso di esempio tra i livelli.

E sì, @Sweaver2112 è perfetto per usare DI. Configurazione semplice, massimo vantaggio.

Answer 2

Bene, hai i pollici del mio laico in alto, questo sembra piuttosto standard. Alcune altre cose da considerare sono: 1) Il tuo livello Dal/Service è interfacciato? e 2) stai usando l'iniezione di dipendenza (passando queste interfacce all'istanza del controller)? In questo modo puoi cambiare implementazioni o deridere facilmente i test unitari.

Questo post sul blog potrebbe essere di interesse.