Wenn Entity Framework/DbContext das DAL/Repository ist, wo passt es in die 3-Tier-Architektur?

Question

Ich habe den ganzen Tag Artikel über StackOverflow und andere Seiten über die besten Architekturpraktiken gelesen und es gibt so viele widersprüchliche Ideen und Meinungen.

Ich habe mich schließlich auf einen Ansatz festgelegt, aber ich habe eine wirklich harte Zeit zu entscheiden, wo die EF-Objekte (DbContext, Fluent APIs, Seeding Daten, etc.) platzieren. Hier ist, was ich derzeit habe:

ASP.NET MVC Projekt: Das eigentliche Web-Projekt. Enthält die Standardansichten, Controller und View-Modelle (in einem Models Ordner).

Domänenmodellprojekt: Enthält alle POCO-Klassen, die die Objekte der Datenbank (Domäne) definieren. Derzeit werden keine EF-Objekte erwähnt oder referenziert.

Dienstschichtprojekt: Enthält Dienstobjekte für jeden Typ von Domänenobjekt (z. B. IProductService, IOrderService usw.). Jeder Dienst verweist auf EF-Objekte wie DbSets und behandelt Geschäftsregeln - z. B. ein Produkt hinzufügen, ein Produkt zu einem Auftrag hinzufügen usw.

Also die Frage ist, in dieser Konfiguration, wo EF-Klassen gehen? Anfangs dachte ich in der Service-Schicht, aber das scheint keinen Sinn zu ergeben. Ich dachte dann, sie in die Domain Model Layer zu bringen, aber dann bindet sie die Domain Models an EF, was im Wesentlichen ein DAL/Repository ist. Schließlich dachte ich darüber nach, ein separates DAL-Projekt nur für EF zu erstellen, aber es scheint eine riesige Verschwendung zu sein, wenn man bedenkt, dass es wahrscheinlich 3-4 Dateien (DbContext und ein paar andere kleine Dateien) enthalten wird.

Kann jemand irgendeine Anleitung zur Verfügung stellen?

Answer 1

Das Domänenmodell ist nicht erforderlich, da es sich um eine Redundanz handelt. EF-Klassen können direkt als Domänenmodell fungieren und werden in Ansichtsmodelle konvertiert, während sie an View gesendet werden. EF kann in verschiedene Klassenbibliotheken unterteilt werden. Die meisten von ihnen verwenden Repository-Muster zusammen mit jedem ORM, wenn es leicht wäre, sie zu ersetzen. Aber ich habe Kritik über die Verwendung von Repository-Muster gesehen, überprüfen Sie this heraus. Hier

Answer 2

ist, was ich tue:

Daten:

• Hat eine Klasse von DbContext vererben.
  • Es hat alle db-Sets.
  • Überschreibt OnModelCreating.
  • Zuordnung von Primärschlüsseln und Beziehungen.

Instanzen:

• alle POCO Klassen hat.
  • Jede Eigenschaft ist mit erforderlichen Datenanmerkungen versehen.

Dienstleistungen:

• Jeder Dienst hat gängige Methoden (GetList(), Suchen(), Create(), etc.).

Geschäft:

• von Clients aufgerufen, orchestrieren Diensten eine bestimmte Aufgabe UserChangePassword auszuführen (dies wird prüfen, ob dies durchgeführt werden kann, ist die Aufgabe auszuführen, oder Fehler/nicht autorisierten Status unter vielen Rück andere das Client zu machen, die richtigen Informationen in Bezug auf die Aufgabe zeigt. Diese auf meinem Fall ist, wo ich lüge.

Clients (Desktop/Web/Wpf/etc).

Ich sage nicht, das ist der beste Ansatz, ich teile nur, was für mich gearbeitet hat.