Ich bin gerade dabei, ein neues Entwicklungsprojekt aufzusetzen, und mir ist nicht klar, wie ich meine Datenbankzugriffsstrategie einrichten soll. Ich werde Visual Studio 2012 verwenden und .NET 5.0 und SQL Server 2008 oder 2012 als Ziel verwenden.
Worüber ich mich nicht sicher bin, ist, ob und in welchem Umfang Entity Framework verwendet wird oder nicht. Da das Lesen von Daten aus der Datenbank und die anschließende Verarbeitung der Hauptaufgabe dieser Anwendung sein wird, ist die Abfrageleistung wichtig. Ich weiß, dass EF5 in dieser Hinsicht viel besser ist als EF4.x, aber es ist nicht der inhärente EF-Aufwand, über den ich am meisten besorgt bin (obwohl etwas wie Dapper mindestens doppelt so schnell ist), sondern eher die Faulheit, die es dir bietet als Entwickler, weil das Abfragen zu viel durch LINQ so einfach ist. Daher möchte ich, dass reine SQL-Abfragen der wichtigste Weg zum Abrufen von Daten sind.
Was ich jedoch am meisten an EF vermisse, ist:
Ich kann ohne Änderungsverfolgung leben, es ist normalerweise nicht so schwer zu bestimmen, was neu oder aktualisiert ist.
Was ich möchte, ist, dass die Entwickler dieses Projekts nicht mit Tischdesignern herumhantieren müssen, sondern einfach POCOs schreiben können. Daher schätze ich den ersten Ansatz von EF sehr. Damit kann ein Entwickler den Quellcode klonen, update-database aufrufen und eine funktionierende lokale Datenbank haben. Es ist etwas, das in der Vergangenheit gut für mich funktioniert hat.
Eine andere Sache, die mir sehr wichtig ist, ist ein Arbeitseinheitsmuster oder die Atomizität von Einfügungen und Aktualisierungen. Ich möchte alle Änderungen anstehen und habe einen einzelnen Punkt, wo ich SaveChanges aufrufen. Bei Bibliotheken wie DapperExtensions erhalten Sie eine Insert -Methode, die jedoch sofort den Datenbankaufruf durchführt. Sie können es atomar machen, indem Sie eine Transaktion um es herum wickeln, aber das ist nicht das Gleiche wie das Einreihen. Also müsste ich dafür selbst einen Warteschlangenmechanismus einrollen.
Für die Kompilierzeit-Abfrageüberprüfung erwäge ich, SQL Server-Datentools (SSDT) zu verwenden. Abfragen würden gespeicherte Prozeduren sein (um große Query-String-Blobs im C # -Code zu vermeiden) und mit SSDT können diese zur Build-Zeit überprüft werden. Ein weiterer Vorteil von SSDT besteht darin, dass Sie die gespeicherten Prozeduren von Visual Studio in einer Zieldatenbank bereitstellen können. Und am wichtigsten, die SQL-Skripte für diese würden in der Quellcodeverwaltung leben.
Damit würde meine Lösung im Wesentlichen aus drei Datenzugriffstechnologien bestehen:
Entity Framework
Attach Entitäten, die Sie über SQL abgerufen haben, in den Kontext einfügen müssen. SSDT
Dapper / anderes Micro ORM
Ich kann nicht anders, als zu glauben, dass dies eine Art Frankenstein-Lösung ist, bei der ich verschiedene Teile von allem benutze. Ich bin mir auch noch nicht sicher, ob SSDT und EF auf eine nette Art zusammenarbeiten werden. Dieses schnelle Beispiel scheint jedoch gut zu funktionieren:
%Vor%Dieser Ansatz scheint so zu sein, als würde er funktionieren, aber er ist auch unordentlich. Aber wenn ich SSDT aufgebe, werde ich die Kompilierzeitprüfung von SQL verpassen, wenn ich Entity Framework aufgäbe, werde ich Code-erste und leichtere Einfügungen vermissen und wenn ich auf geraden SQL verzichten werde, werde ich es vermissen auf einem großen Stück Leistung.
Gibt es eine Alternative, die ich übersehe? Wenn nicht, was ist der beste Ansatz hier?
Tags und Links c# entity-framework ssdt dapper