ASP.NET MVC, livelli, Modelli, repository ecc

Question

Ho alcune domande dopo aver letto un articolo intitolato Layered Application Guidelines (http://msdn.microsoft.com/en-us/library/ee658109.aspx).

Per esempio, Ho un'applicazione ASP.NET MVC. Nella mia applicazione ho alcune Entità (Modelli), Archivi, UnitOfWork e DbContext. E alcune viste e controller pure.

Come dividerli in strati secondo un articolo di cui sopra?

Per quanto ho capito, viste e controllori (forse) risiedono in un livello di presentazione. Entità (Modelli) in Business Layer e repository, UnitOfWork e DbContext in livello dati.

Ho ragione o errore? Sono molto molto insicuro a riguardo.

Grazie in anticipo!

Answer 1

viste e controllori devono risiedere nel livello di presentazione. I tuoi modelli dovrebbero risiedere anche nel livello di presentazione. I modelli riflettono un modello di vista che viene utilizzato solo per la presentazione. Le entità devono rappresentare i dati e non devono essere inviati alla vista. Nella presentazione successiva, i modelli devono essere compilati dalle entità. Hai ragione nel fatto che DbContext e UnitOfWork dovrebbero trovarsi nel livello dati.

Answer 2

Il modo gli strati sono separati dipenderà dalla portata dell'applicazione. Per un piccolo, le aree possono essere sufficienti. Per un progetto più grande, o un progetto che potrebbe diventare grande, dovresti cercare di creare soluzioni separate per ogni livello. Questo è noto come approccio a più livelli e può essere visto osservando l'eccellente esempio su http://prodinner.codeplex.com/.

Answer 3

entità Entity Framework (insieme con il quadro) sono la parte dati. In molte applicazioni entrano anche a far parte del tuo livello aziendale ed è discutibile se questo sia o meno valido (personalmente non mi piace, ma quando lo si riassume con il modello del repository c'è una buona argomentazione che stai perdendo alcuni dei benefici forniti da EF).

A seconda del modo in cui si separa il codice (e sembra che si stia utilizzando il modello di repository) si può avere un repository contenente alcune logiche di business o anche un livello di servizi (la mia preferenza per le applicazioni a 3 livelli) dove la logica aziendale (principalmente) accade.

Direi che dovresti considerare View Models e parte del tuo modello di presentazione, ma se utilizzi MVC e annotazioni di dati (che sono eccellenti per questo lavoro) per convalidare il tuo modello hai appena accumulato un un mucchio di logica aziendale in loro.

Il punto più importante per impedire che la logica aziendale si insinui è il livello di presentazione e, soprattutto, le visualizzazioni e i controller. L'approccio al modo in cui strutturate il resto dell'applicazione dipende in gran parte dal framework scelto, dalla scala dell'applicazione e dalla struttura di distribuzione dell'applicazione.

Quindi, per essere il più chiaro possibile questo è quello che faccio *:

Visualizzazioni < --Presentation strato solo

Controller < --Presentation strato unico (potrebbe finire in alcuni casi con controller leggermente "grasso", ad es. login .NET Membership)

Visualizza Modelli < - Livello di presentazione, ma se si fanno le convalide qui spesso vengono testate anche le regole aziendali.

Servizio strato < --Business strato strato se utilizzati

Repositories < --Could essere dati soltanto, o mix di livello di business. Se fate il modello repository cercare di evitare di esporre le vostre DbSets direttamente, in quanto questo sconfigge subito l'astrazione che si sta tentando di fornire (potenziali eccezioni a questo, ad esempio - Net Membership)

Enti < strato --data, possibilmente con una logica di business in base alla struttura della tua applicazione.

* non deve essere preso come autorevoli

Answer 4

• Visualizza i modelli/Vista/Controller - presentazione strato
• Enti - strato di business

The repository mediates between the data source layer and the business layers of the application

Il DbContext Represents a combination of the Unit-Of-Work and Repository patterns, quindi se stai implementando un repository e un'unità di lavoro in cima potrebbe significare che dovresti prendere in considerazione il limit your abstractions. (Questo ultimo punto potrebbe non essere applicabile nel tuo caso, non potrei dire senza sapere di più sul tuo design).