ASP.NET MVC, Schichten, Modelle, Repositories usw.

Question

Ich habe einige Fragen nach dem Lesen eines Artikels namens Layered Application Guidelines (http://msdn.microsoft.com/en-us/library/ee658109.aspx).

Zum Beispiel habe ich eine ASP.NET MVC-Anwendung. In meiner Anwendung habe ich einige Entitäten (Modelle), Repositories, UnitOfWork und DbContext. Und einige Ansichten und Controller.

Wie teilt man sie in Schichten gemäß einem Artikel oben?

Soweit ich verstehe, befinden sich Ansichten und (möglicherweise) Controller in einer Präsentationsschicht. Entitäten (Modelle) in Business Layer und Repositories, UnitOfWork und DbContext in Data Layer.

Bin ich richtig oder falsch? Ich bin sehr, sehr unsicher darüber.

Vielen Dank im Voraus!

Answer 1

Ansichten und Controller sollten in der Präsentationsschicht befinden. Ihre Modelle sollten sich auch in der Präsentationsebene befinden. Modelle spiegeln ein Ansichtsmodell wider, das nur für die Präsentation verwendet wird. Entitäten sollten Daten darstellen und nicht an die View gesendet werden. In der späteren Präsentation sollten die Modelle von den Entitäten ausgefüllt werden. Sie haben Recht, dass Ihr DbContext und UnitOfWork in der Datenschicht sein sollte.

Answer 2

Die Art der Trennung der Layer hängt vom Umfang Ihrer Anwendung ab. Für einen kleinen Bereich können Bereiche ausreichen. Für ein größeres Projekt oder ein Projekt, das möglicherweise groß wird, sollten Sie separate Lösungen für jede Ebene erstellen. Dies ist als n-Tier-Ansatz bekannt und kann bei Betrachtung des ausgezeichneten Beispiels bei http://prodinner.codeplex.com/ gesehen werden.

Answer 3

Entity Framework-Entitäten (zusammen mit dem Framework) sind Ihre Datenschicht. In vielen Anwendungen werden sie auch Teil Ihrer Business-Schicht - und es ist fraglich, ob das gut ist oder nicht (ich persönlich mag das nicht, aber wenn Sie es mit dem Repository-Modell abstrahieren, gibt es ein gutes Argument, dass Sie verlieren einige der Vorteile von EF).

Je nachdem, wie Sie Ihren Code trennen (und es klingt wie Sie das Repository-Muster verwenden) haben Sie möglicherweise ein Repository mit einigen Geschäftslogik, oder eine Services-Schicht (meine Präferenz für 3-Tier-Anwendungen) wo Geschäftslogik (meistens) passiert.

Ich würde argumentieren, dass Sie View-Modelle sowie Teil Ihres Präsentationsmodells betrachten sollten - aber wenn Sie MVC und Daten-Annotationen (die für diesen Job hervorragend sind) verwenden, um Ihr Modell zu überprüfen, haben Sie gerade angehäuft Haufen von Geschäftslogik in ihnen.

Der wichtigste Ort, an dem sich die Geschäftslogik nicht einschleichen kann, ist Ihre Präsentationsebene und vor allem Ihre Ansichten und Controller. Der Ansatz, wie Sie den Rest Ihrer Anwendung strukturieren, hängt stark von dem von Ihnen gewählten Framework, der Größe Ihrer Anwendung und der Bereitstellungsstruktur der Anwendung ab.

So so klar wie möglich zu sein, das ist, was ich tun *:

Ansichten < --Presentation Schicht nur

Controller < --Presentation Schicht nur (vielleicht am Ende mit leicht "fetten" Controller in einigen Fällen, z. B. .NET Mitgliedschaft anmelden)

Modelle anzeigen < - Präsentationsebene, aber wenn hier Prüfungen durchgeführt werden, werden häufig auch Geschäftsregeln getestet.

Service Layer < --Business Schicht, wenn verwendet

Repositorys < --Could nur Datenschicht sein, oder Mischung aus Business-Schicht. Wenn Sie das Repository-Muster zu tun versuchen zu vermeiden und Ihre DbSets direkt auszusetzen, da dies sofort die Abstraktion besiegt versuchen Sie (mögliche Ausnahmen, zB - Net Mitgliedschaft), um

Entities < --Datenzurückhalten Schicht, möglicherweise auch mit Geschäftslogik, je nachdem, wie Sie Ihre Anwendung strukturieren. Präsentationsschicht

Entities - -

* nicht als autoritative

Answer 4

• Ansicht Modelle/Ansichten/Controller genommen werden Business-Schicht

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

Die DbContext Represents a combination of the Unit-Of-Work and Repository patterns, wenn Sie also ein Repository und eine Arbeitseinheit implementieren Spitze davon könnte bedeuten, dass Sie limit your abstractions berücksichtigen sollten. (Dieser letzte Punkt trifft in Ihrem Fall möglicherweise nicht zu, könnte ich nicht sagen, ohne mehr über Ihr Design zu erfahren).