Ich verwende das Entity Framework 4.1 und ASP.Net MVC 3 für meine Anwendung. MVC bietet die Präsentationsschicht, eine Zwischenbibliothek bietet die Geschäftslogik und die Entity Framework Art von Handlungen als die Datenschicht, denke ich?
Ich könnte den Entity Framework-Code in eine Gruppe von Repository-Klassen oder eine entsprechende Abwandlung davon aufteilen, was auch immer eine wertvolle Datenschicht darstellt, aber ich habe Probleme, ein Designproblem zu lösen, das ich habe.
Wenn der mehrschichtige Ansatz existiert, der mir hilft, Probleme getrennt zu halten, dann liegt es nahe, dass meine Wahl der Datenpersistenz auch kein Thema der Präsentationsebene sein sollte. Das Problem ist, dass ich mit der Verwendung des Entity Framework meine Anwendung im Grunde eng mit der Vorstellung verknüpfe, dass Entitätsänderungen automatisch nachverfolgt und beibehalten werden.
Nehmen wir als Beispiel an, in einer hypothetischen Welt habe ich einen Grund gefunden, das Entity Framework nicht zu verwenden und es auszutauschen. Eine gut konzipierte Lösung sollte es mir ermöglichen, dies auf der entsprechenden Ebene zu tun und keine abhängigen Ebenen betroffen zu haben. Da jedoch der gesamte Code mit dem Wissen geschrieben wird, dass die Datenschicht Objektänderungen verfolgt, wäre ich nur in der Lage, die Entität auszutauschen Framework für etwas, das auf ähnliche Weise funktioniert, zum Beispiel nHibernate.
Wie kann ich das Entity Framework verwenden, muss aber meinen Code nicht so schreiben, dass angenommen wird, dass Entitätsänderungen von der Datenschicht verfolgt werden?
UPDATE für diejenigen, die sich noch immer über dieses Problem in ihren eigenen Szenarien Gedanken machen:
Ayende Rahien schrieb einen großartigen Artikel, der dieses ganze Argument abtut:
Ссылка
Wenn Sie auf diese Weise weitermachen möchten, sollten Sie Programmierarbeit aufgeben und Philosophie studieren. Entity-Framework ist Abstraktion der Persistenz und es gibt eine Regel von Leaky Abstraktion , die besagt, dass jede nicht-triviale Abstraktion zu einem gewissen Grad ist undicht.
Agile Methodologien haben ein sehr interessantes Phänomen: Bereiten Sie sich nicht auf hypothetische Situationen vor. Die meiste Zeit ist es nur Vergoldung . Jede Änderung hat ihre Kosten. Das Ändern der Persistenzschicht später im Projekt ist kostspielig, aber auch sehr selten. Aus Kundensicht gibt es keinen Grund, einen Teil dieser Kosten in den meisten Projekten zu bezahlen, in denen diese Änderung nicht benötigt wird. Wenn wir die Kundenperspektive tiefer diskutieren, können wir sagen, dass er das überhaupt nicht bezahlen sollte, denn die Wahl einer schlechten API, die später ersetzt werden muss, ist ein Versagen von Entwicklern / Architekten. Refactorieren Sie Ihren Code regelmäßig, aber nur so weit, dass neue Funktionen hinzugefügt werden können, die der Kunde benötigt, ansonsten können Sie kaum auf dem Markt konkurrieren. Dies hat natürlich einige Ausnahmen:
Nun zu Ihrem Problem. Wenn Sie eine solche Abstraktion auf hohem Niveau wünschen, sollten Sie die Entitäten nicht Ihrem Controller zugänglich machen. Setzen Sie DTOs aus der Business-Schicht (oder sogar aus Repositories) frei und fügen Sie diesen DTOs Felder wie IsNew, IsModified, IsDeleted hinzu. Jetzt ist Ihre Benutzeroberfläche vollständig von der Persistenz getrennt, aber Ihre Architektur ist viel komplexer und es gibt wahrscheinlich keinen Grund für eine solche Komplexität - sie ist überstrukturiert. Eine andere Möglichkeit besteht darin, Tracking einfach auszuschalten (fügen Sie AsNoTracking() zu jeder Abfrage hinzu) und Proxy-Erstellung für Ihre Entitäten ( context.Configuration.ProxyCreationEnabled ) - Lazy Loading funktioniert nicht so gut. Das ist wie das Wegwerfen der meisten Features, die Ihnen Persistenz-Frameworks bieten.
Es gibt auch andere Standpunkte. Ich empfehle Ihnen, Ayendes jüngste Beiträge über das Repository und seine Kommentare zu Sharp Architektur zu lesen.
Kurze Antwort? Du nicht. Sie könnten das Tracking von EF ausschalten und sich dann nicht darum kümmern, aber das ist es schon.
Wenn Sie Ihre Präsentationsschicht mit der Erwartung schreiben, dass Änderungen automatisch nachverfolgt und beibehalten werden, muss das, wofür Sie EF ersetzen, dies auch tun. Sie können es nicht für etwas auslagern, das Änderungen nicht automatisch nachverfolgt und festhält und nur erwartet, dass die Dinge weiter funktionieren. Das wäre so, als würde man ein System nehmen, das auf einer TCP / IP-Verbindung für die Duplex-Kommunikation beruht, indem man es an eine HTTP-Verbindung (die eigentlich nicht Duplex ist) wechselt und erwartet, dass die Dinge genauso funktionieren. Tut es nicht.
Wenn Sie Ihre Persistenzebene für etwas anderes austauschen möchten und nichts anderes ändern müssen, müssen Sie EF (oder was auch immer) in Ihren eigenen benutzerdefinierten Code einfügen, um die gewünschte Funktionalität bereitzustellen. Dann müssen Sie Implementierungen für alles bereitstellen, was nicht durch das, was Sie austauschen, bereitgestellt wird.
Das ist machbar, aber es wird eine Menge Arbeit für ein Problem sein, das sehr selten passiert. Dies wird dem Projekt zusätzliche Komplexität verleihen. Ladislav ist großartig: Es lohnt sich nicht, so weit zu abstrahieren.
Sie sollten das Repository-Muster und das einfache POCOS implementieren, wenn Sie Bedenken haben, EF möglicherweise auszutauschen.
Es gibt ein großartiges Projekt auf Codeplex, das domänengestütztes Design einschließlich Dokumentation durchläuft. Sieh dir das an.
Bitte lesen Sie nach dem Lesen des Microsoft N-Layer-Projekts ayenede's Weblog Mr.ayende schrieb Serienbeiträge über Vorteile und Nachteile von Microsoft N-Layer-Projekt.
Tags und Links entity-framework entity-framework-4.1 architecture orm separation-of-concerns