Hat schon mal jemand während der Entwicklung zwischen ORM-Lösungen gewechselt?

Question

In meinem aktuellen Job habe ich die Repository/UoW-Muster auf EntityFramework und DbContext implementiert. Die einzigen gültigen Gründe, die ich dafür gefunden habe, wären, wenn Sie nicht auf eine bestimmte ORM-Lösung angewiesen wären. Ich wollte nur sehen, ob irgendjemand das jemals getan hat und auf halbem Weg durch das Projekt (sagen wir, ein Jahr später) entschied: "Meine Güte, ich bin froh, dass ich dieses Repository-Muster implementiert habe, weil ich von EntityFramework zu NHibernate wechseln muss. " Abgesehen von crud und einigen grundlegenden Abfragen mit Joins (mit LINQ) empfinde ich diese zusätzliche Ebene der Abstraktion als lästig, da Sie die Tabelle in der Datenbank erstellen, ein Repository schreiben, einen Service schreiben müssen (wenn Sie die typischen 3 Tiered Arch) und das notwendige Frontend wie ein Controller und Ansichten.

Update:

Möchten wissen, ob jemand an einem Projekt wechseln ORM hat vor und warum?

Answer 1

Sie müssen dies nicht tun. Ich bin mir nicht bewusst, dass ein Projekt tatsächlich umgestellt wurde, und der Wechsel wird sowieso viel Arbeit beinhalten. Wenn Sie Ayende's blog lesen, werden Sie viele Punkte gegen Repositories finden.

Der einzige Grund dafür ist, wenn Sie ein Framework entwickeln, das mit mehreren ORMs basierend auf einem bestimmten Anwendungsfall verwendet werden kann.

Darüber hinaus ist ein Repository pro Tabelle sehr verschwenderisch Entwickler Zeit.
Auch wenn Sie mit Repositorys arbeiten, sollte ein generisches Repository mit einigen Entity-spezifischen Erweiterungen mehr als genug sein.

Nachdem ich das alles gesagt habe, benutze ich immer noch Repositories, hauptsächlich weil ich direkte Verweise auf Bibliotheken von Drittanbietern in nicht verwandtem Code nicht mag. Aber das ist eine Frage der Präferenz und keine bewährte Praxis, die ich beweisen kann.

Answer 2

Es gibt viele Microsoft-Blogs, die vorschlagen, das Repository-Muster zu verwenden.

Diese Google-Suche nach "Entity Framework Unit of Work" dies zurück.

entity framework unit of work

Ich denke, was noch wichtiger in Ihrem Code, um sicherzustellen, es ist wartbar und flexibel ist SOLID Prinzipien zu folgen. Insbesondere das Interface-Segregationsmuster. Wenn Sie für Schnittstellen codieren, wird die Implementierung des Daten-Repository irrelevant, wenn Sie Schnittstellen codieren.

Ich benutze Azure Blob Storage-Daten zu speichern manchmal, so habe ich zwei Implementierungen meiner Schnittstelle:

IDtoEntityRepository

ich den gleichen Datentyp aus zwei verschiedenen Datenspeichern ziehen und jeder Datenspeicher hat unterschiedliche Anforderungen für das Arbeiten mit den Daten. Also ich am Ende mit 1 SQL-Implementierung und 1 Azure Blob Storage-Implementierung. Die SQL-Implementierung geschieht mit Entity Framework kodiert werden, aber ich konnte eine neue Klasse Code mit Telerik Orm leicht Code aufgerufen:

TelerikOrmDtoEntityRepository 

alle Klassen, die gegen IDtoEntityRepository codiert wurden nicht kümmern uns um die Umsetzung. Auf diese Weise habe ich alle Datenschicht-Implementierungsdetails von dem aufrufenden Code entkoppelt.

Answer 3

Erstellen Sie einfach die minimalen Objekte, die Sie benötigen, um schnell getesteten und zuverlässigen Funktionscode zu liefern. Danach kümmern Sie sich vielleicht um das Refactoring usw., und eines Tages, wenn Sie sich für einen Wechsel des ORM-Tools entscheiden, werden Sie Ihre Hände schmutzig machen, indem Sie mit dem Mechaniker spielen, beispielsweise mit dem Repository und den Arbeitsmustern.

Abgesehen davon, wenn Sie bereits mit dem Repository-Muster vertraut sind, könnte dies eine gute Idee, seine Nützlichkeit vorherzusehen, da dies möglicherweise nicht nur ORM-Tool ändern, sondern ADO.NET möglicherweise direkt dann unter bestimmten verwenden Umstände.

Ich glaube, es ist nicht schlecht, sich auf Tools von Drittanbietern wie einem ORM oder dergleichen zu verlassen, und dann denke ich, dass Sie für die besten bewerteten arbeiten möchten, das ist zum Beispiel NHibernate, die ich vor jedem bevorzuge andere ORM-Werkzeuge, die existieren. Und das ist eine persönliche Meinung.

Die Idee hinter dem, was ich sage, ist nicht eine Reihe von Klassen zu schreiben, nur für den Fall, dass Sie sie irgendwann brauchen könnten. Schreibe sie, wenn du sie wirklich brauchst.