Kann ich in einem separaten Layer für Datenzugriff und Geschäftslogik Entity-Framework-Klassen in der Business-Schicht verwenden?

Question

In separaten Datenzugriff & Business-Logik-Ebene, kann ich Entity-Framework-Klassen in der Business-Schicht verwenden?

EDIT: Ich glaube nicht, ich muss die Datenzugriffsebene aus meiner Geschäftslogik in der Zukunft austauschen (d. H. Wird SQL Server sein), aber ich werde für die UI-Schicht. Daher ist die Frage eher, gibt es irgendwelche größeren Probleme mit der Verwendung von EF-Klassen für mich in der Business-Schicht? Es scheint, als gäbe es weniger Klempnercode.

Answer 1

Typischerweise ist der „best practice“ Ansatz so etwas wie dies wäre:

• in Ihrer Datenschicht, haben Sie EF Entitäten, die von und gespeichert zurück in die Datenbank in

• geladen werden In Ihrer Business-Schicht haben Sie Ihre eigenen Domänenobjekte (einfache C# -Klassen), die die Daten darstellen, an denen Ihre App arbeiten muss. Diese können mehr oder weniger identisch mit einer Datenebenenentität sein oder sie können mehrere "atomare" Entitäten enthalten, um ein Geschäftsobjekt zu bilden, oder sie können sich erheblich unterscheiden. Um die Notwendigkeit vieler Links-rechts-Zuweisungsanweisungen zu verringern (um Eigenschaftswerte zwischen Datenebenen-Entitäten und Business-Schicht-Objekten hin und her zu verschieben), sollten Sie Tools wie AutoMapper ausprobieren, die es wirklich einfach machen up „Zuordnungen“ zwischen ähnlichen Objekttypen und ermöglicht es Ihnen, diese Typen hin und her

• UI-Schicht (en) leicht zuweisen wird dann visualisieren und Business-Schicht-Objekte den Benutzer zur Information darstellen und/oder Manipulation

Der Vorteil ist, dass Ihr Business-Schicht-Domänenmodell die tatsächlichen Geschäftsobjekte darstellt, mit denen Sie arbeiten, und mehr oder weniger unabhängig davon wird, wie diese aussehen re wirklich in der Datenschicht gespeichert. Dies verhindert auch das "Kleben" Ihrer UI-Ebene an eine bestimmte Datenzugriffstechnologie.

Natürlich ist dies das empfohlene Best Practice für eine Enterprise-App, wo Sie die Datenzugriffsschicht usw. austauschen müssen. Für eine einfachere App können Sie diese Praktiken überspringen, wissen,, was Sie sind tun, und dass Sie sich in EF "einsperren", wenn Sie EF-Entitäten den ganzen Weg durch die Business-Schicht in der Benutzeroberfläche verwenden. Wenn das für Sie und Ihr App-Szenario in Ordnung ist, gibt es keinen besonderen Grund, dies nicht zu tun. EF-Entitäten sind perfekt gültige .NET-Objektklassen - sie leiten sich einfach von einer gemeinsamen Basisklasse ab (EntityObject anstelle von object) und sie haben eine gewisse Menge an "Gepäck", das mitkommt. Aber nichts hindert Sie daran, diese EF-Elemente in Ihrer gesamten App zu verwenden.

Answer 2

Wie bei allen Fragen dieser Art hängt die Antwort davon ab. Wenn Sie eine klare Trennung Ihrer Datenzugriffslogik und Business-Ebene möchten, würde ich nein sagen. Wenn dies das ist, was Sie anstreben, würde ich ein Repository-Muster und IoC verwenden, um die Datenzugriffsebene zu erstellen, dann können Sie in einem Stub DAL zu Unit-Testzwecken tauschen und dann den Datenbankzugriff einbringen, wenn Sie zum Funktionstest kommen.

Answer 3

Wenn Sie die Art und Weise ändern müssen, wie Sie auf die Datenbank zugreifen, ohne viel Code neu schreiben zu müssen, sollten Sie EF besser aus der Business-Schicht heraushalten. Sie könnten die Arbeitseinheits- und Repository-Muster verwenden, um dies zu erreichen. Zugriff auf alle Funktionen der Datenebene über Schnittstellen. Wenn Sie EF löschen, bleiben die Schnittstellen gleich, Sie ändern nur die implementierenden Klassen.

Es gibt jedoch Argumente für die Verwendung von UoW und Repository, die wichtigste ist, dass der DbContext bereits viele dieser Funktionen bietet.

Ich startete ein Projekt mit einem UoI und Repository auf der Datenschicht und keine EF-Referenzen auf der Business-Schicht. Als ich Fortschritte machte, fühlte ich, dass ich nur Arbeit für mich machte und sie fallen ließ. Stattdessen verwende ich den Kontext von der Geschäftsschicht, führe jede Konvertierung durch, die ich von DTO zu Geschäftsschicht POCO benötige.

In meinem Szenario bin ich zuversichtlich, bei EF bleiben. Wenn Sie nicht sind, überlegen Sie, welcher Ansatz zu Ihnen passt.