Ich bin dabei, eine mittelgroße ASP.Net MVC-Anwendung zu entwickeln. Ich versuche, das Design richtig zu machen. Ich beabsichtige, folgende Schichten zu haben:
Ich werde Unity als meinen IOC-Container und EF4.1-Code zuerst für den Datenzugriff verwenden.
Die App wird in mehrere Assemblies aufgeteilt. Ich habe ein Problem damit zu entscheiden, welche Baugruppen ich brauche und wo man das folgende setzt:
Meine Frage ist: Wie teilen Sie normalerweise Ihre und warum?
Bearbeiten: Wird durch die Antwort von @ TheHurt ausgelöst.
Wie würden die Referenzen zwischen den Assemblies sein, d. h. welche Assembly würde auf welche verweisen?
So könnte ich es angehen:
App.UI-Assembly:
App.Repository-Assembly:
App.Repository.SQL:
App.Services-Assembly:
App.Services.Implementation:
App.Common:
Es gibt ein paar Probleme, mit denen ich immer noch zu kämpfen habe. Sie verlieren die Datenanmerkungen von EFCF, wenn Sie die Dienstgrenze überschreiten. Also müssen Sie die serverseitige Validierung durchführen, oder Sie müssen Ihre Ansichtsmodelle synchron mit den Repository-Entitäten validieren. Es fühlt sich an, je mehr Dinge übereinander liegen, desto mehr wird DRY verletzt. Ich nehme an, dass das für den Kurs zwar normal ist, wenn Ihre Ansichtsmodelle nicht direkt auf Ihre Entitäten abgebildet werden. Du könntest deine Ansichtsmodelle deine DTOs sein lassen und sie in die Gemeinsame Versammlung werfen, aber das scheint Dinge zu eng zu koppeln, wenn du extrem flexibel mit deinen Diensten sein musst.
BEARBEITEN
Wenn Sie WCF in den Mix integrieren möchten, sollten Sie wahrscheinlich Datenverträge erstellen, die dem MVC-View-Modell sehr nahe kommen (oder die Verträge als View-Modell verwenden). Sie würden das wahrscheinlich nicht der Welt aussetzen, da der Dienst spezifisch für diese Implementierung Ihrer MVC-Site sein würde, und einen anderen Dienst für den öffentlichen Verbrauch bereitstellen. Wenn Sie einen WCF-Dienst ausführen, möchten Sie wahrscheinlich alle Ihre Geschäftslogik im Dienst haben, die Controller würden nur Navigationslogik behandeln.
Seitliche Anmerkung, ich versuche, so weit wie möglich von dem "Metall" wegzubleiben, während ich ein Design entwickle, das es mir ermöglicht, den Code in Zukunft in verschiedene Ebenen zu trennen. Wenn ich meinem Manager mit einem Blatt Papier nicht die verschiedenen Systemschichten erklären kann, ist das Design mehr als wahrscheinlich zu komplex. In Visio sieht alles gut aus, wenn es gut gestaltet ist.
So wie sich die Dinge gegenseitig referenzieren: UI würde das Service (oder die Service-Implementierung, die möglicherweise nicht benötigt wird, an die gleiche Stelle halten). Service refs das Repository. Die Repository-Implementierung verweist auf nichts, da sie von IOC geladen wird. Alles verweist auf Common.
Tags und Links asp.net-mvc repository-pattern