ASP.NET MVC mit Serviceschicht und Repository -Ebene, wo sollten die Schnittstellen definiert werden?

Question

Ich bin dabei, eine ziemlich einfache Schichtarchitektur für eine .NET -MVC -Anwendung mit einer Repository -Ebene und einer Serviceschicht zu bestimmen. Ich habe einige ziemlich klare und einfache Beispiele gefunden, insbesondere www.asp.net, und einige Fragen und Antworten hier, aber ich suche etwas, das ein wenig einfacher ist, geeignet für kleine Anwendungen, aber das verwendet verschiedene Projekte, um die Idee zu vermitteln. Das Beispiel, mit dem ich oben verknüpft bin, hat das Repository und den Dienst als Klassen im Modelle Namespace. Das ist einfach nicht genug von einer klaren Trennung für mich, um sie richtig zu veranschaulichen.

Ich habe ein separates Projekt für das Repository, das das Schnittstellen -Irepository implementiert. Es gibt ein separates Projekt für den Dienst, der Iservice implementiert und ein Irepository (Konstruktorinjektion) nimmt. Der Service implementiert Iservice. Für dieses Beispiel reicht es aus, dass der Controller den Dienst instanziiert und noch keinen IOC -Container benötigt. Stellen Sie sich dies als einen Zwischenschritt vor, um die besten architektonischen Praktiken zu verstehen, Teil einer Sequenz, die zunehmend zur Abhängigkeitsinjektion und möglicherweise mehr Schichten baut.

Die Frage ist, wo soll ich Irepository und Iservice definieren? Natürlich müssen sowohl die Service- als auch die Repository -Projekte auf sie verweisen. Es scheint dann klar, dass sie in einem anderen Projekt definiert werden sollten, auf das sowohl die Dienst- als auch die Repository -Projekte verwiesen werden. Wenn ja, was wäre eine gute Namenskonvention? So etwas wie xxxxconcracts?

Ist es für die Datenmodelle, die zwischen den Präsentations-, Dienst- und Repository -Ebenen bestanden werden, akzeptabel, ein separates Projekt namens XXXXModels zu haben, auf das alle Ebenen verwiesen werden? Ich verstehe, dass die Modelle in einigen Fällen zwischen der Dienst- und Repository -Ebene über die zwischen der Serviceschicht und der Präsentationsschicht übergebenen Personen abweichen können, aber das Prinzip ist gleich.

Ich habe hier Antworten auf ähnliche Fragen gefunden, aber sie beinhalten eine kompliziertere Architektur als das, was ich hier beschrieben habe. Ich möchte eine wirklich einfache und saubere Abbildung der beiden Ebenen erreichen, die als ein oder zwei Schritte angesehen werden können, die auf die Datenschicht verweisen und Geschäftslogik in den Controllern haben, das ist alles. Ich weiß, dass es ein starkes und gültiges Argument dafür gibt, dass sie direkt zu den besten Practice-Praxis gehen, aber nicht jeder ist geeignet, diesen Sprung auf einmal zu machen.

Answer 1

Einführung

Das habe ich mich auch gefragt. Eine brennende Frage, die ich immer habe, ähnelt Ihnen;

Was wäre eine gute Namenskonvention?

Wie soll ich Dinge nennen? Sollten sie in Ordner oder Projekte gehen?

Nachdem ich herum gesucht habe, vermute ich, dass die Antwort das ist Es spielt keine Rolle. Wichtig ist, dass Ihre Lösung eine vernünftige Architektur hat und Sie versuchen, gute Praktiken wie zu verfolgen, z. FEST.

Meine ASP.NET -MVC -Helden zu diesem Thema sind Jeffrey Palermo, Steve Smith und Jimmy Bogard.

Zwiebelarchitektur

Jeffrey Palermo diskutiert eine Kombination alter Ideen, bringt sie aber zusammen und gibt ihm den visuell anregenden Namen von Zwiebelarchitektur (Eine empfohlene Lektüre). Jeffrey zeigt eine gute Herangehensweise an das Problem, wohin Dinge gestellt werden sollen. Er erklärt, dass Sie in der Mitte (oder oben) Ihrer Bewerbung Ihre haben Kern. In dieser Ebene sollten Sie Schnittstellen wie z. IRepository und IService.

Fast alle Ihre Schnittstellen sollten im Kern gehen und alles andere (andere Projekte) können alle auf den Kern verweisen. Auf diese Weise kennt alles die Skelettstruktur der Anwendung, ohne die Implementierungsdetails zu kennen.

Versuchen Sie, Ihre UI -Schichtreferenz so wenig wie möglich (innerhalb von Grund) zu haben. In einer meiner Anwendungen verweist meine UI (MVC) -Schicht nur auf den Kern. Alles, was es braucht, wird in sie injiziert Abhängigkeitsspritze.

Steve Smith diskutiert Zwiebelarchitektur und ähnliche Ideen mit Demonstrationen in MVC -Lösung Best Practices: Eine Lösung für das Lösungsproblem

Meine Lösung

In meinen MVC -Lösungen habe ich eine typische Struktur wie diese:

• MyProject.core
• MyProject.domain
• MyProject.DependencyInjection
• MyProject.infrastructure
• MyProject.Web
• MyProject.tests

Das Kern Enthält meine Schnittstellen. Es ist normalerweise in Ordner wie Dienste, Modelle, Domäne, Repositorys usw. unterteilt.

Das Domain Layer verweist nur auf den Kern und enthält meine Implementierung. Es bietet viele Betonklassen für die Domänenabstraktion im Kern. Es befasst sich mit viel Geschäftslogik, Verarbeitung, Befehlsbearbeitung, Managerklassen, konkreten Service -Implementierungen usw. Ich betrachte es für eine ziemlich innere Schicht, und so verweist es so wenig wie möglich.

Das Abhängigkeitsspritze Layer enthält mein ausgewähltes DI -Paket/Framework- und Implementierungsdetails. Ich betrachte es als äußere Schicht; Ähnlich wie die Benutzeroberfläche oder die Infrastruktur und daher ist es in Ordnung, wenn sie viel verweist. Es ist nicht erforderlich, dass diese Ebene ein separates Projekt ist, und viele Leute werden Ihnen sagen, dass Sie dies nicht tun sollen. Das ist okay; Tun Sie, was für die Komplexität Ihres Projekts funktioniert. Ich mag es, wenn mein DI sein eigenes Ding ist. Das Gute daran, dass es so getrennt ist, ist, dass ich das DI -Framework durch ein anderes ersetzen könnte und die Dinge in Ordnung sind. Keine Ebenen verweisen auf das DI -Projekt.

Das Infrastruktur Layer enthält Informationen zu Protokollierung, E -Mail und Datenzugriff. Es wird meine enthalten Orm nach Wahl. Es ist kein geschäfteslogisches Zeug und es ist kein UI-Zeug. Es ist die Eisenbahn meiner Lösung, um Dinge zu erledigen. Es ist auf der äußeren Schicht, verweist aber nur den Kern.

Das Netz Layer ist mein MVC -Projekt und verweist nur auf den Kern.

Komplexität und letzte Gedanken

Ich habe hier Antworten auf ähnliche Fragen gefunden, aber sie beinhalten eine kompliziertere Architektur als das, was ich hier beschrieben habe

Es ist ein guter Punkt. Es ist wichtig, die Komplexität Ihres Problems zu berücksichtigen. Aber lassen Sie sich nicht von guten Lösungspraktiken abschrecken. Meine Lösung und meine Zwiebelarchitektur sind nicht unbedingt sehr komplex und aufblähen Ihre Lösung nicht wirklich. Sie halten die Dinge einfach getrennt.

Im Evolutionsprojektstruktur, Jimmy Bogard spricht darüber, dass Dinge überkomplex sind. Wenn das, was ich gesagt habe, zu komplex erscheint, folgen Sie Jimmys Rat und geben Sie alles in das eine Projekt (Ihre UI -Ebene). Das ist in Ordnung - solange es zu dir passt.

Denken Sie daran, meine Lösung nur als Idee zu nehmen - etwas zu beachten; Mein Ansatz ist ein Versuch, dem Besten den Ratschlägen des Besten zu folgen, aber ich bin sicher, ich habe es nur so sehr gelungen. Ich kann (und muss) noch verbessern.