Entity Framework VS LINQ zu SQL VS ADO.NET mit gespeicherten Prozeduren? [geschlossen]

Wie würden Sie jeden von ihnen bewerten in Bezug auf:

1. Performance
2. Entwicklungsgeschwindigkeit
3. Ordentlicher, intuitiver, wartbarer Code
4. Flexibilität
5. Insgesamt

Ich mag mein SQL und war schon immer ein eingefleischter Fan von ADO.NET und gespeicherten Prozeduren, aber ich hatte kürzlich ein Spiel mit Linq to SQL und war überwältigt davon, wie schnell ich meine DataAccess-Ebene ausgeschrieben habe und mich für Ausgaben entschieden habe einige Zeit wirklich entweder Linq to SQL oder EF verstehen ... oder keine?

Ich möchte nur überprüfen, ob es bei keiner dieser Technologien einen großen Fehler gibt, der meine Forschungszeit unbrauchbar machen würde. ZB ist die Leistung schrecklich, sie ist cool für einfache Apps, kann Sie aber nur so weit bringen.

Update: Können Sie sich auf EF VS L2S VS SPs anstatt auf ORM VS SPs konzentrieren? Ich interessiere mich hauptsächlich für EF VS L2S. Aber ich bin sehr daran interessiert, sie auch mit gespeicherten Prozessen zu vergleichen, da ich über einfaches SQl viel weiß.

Wenn Sie ein neues Projekt starten, entscheiden Sie sich zunächst für Entity Framework ("EF") - es generiert jetzt viel besseres SQL (eher wie Linq to SQL) und ist einfacher zu warten und leistungsfähiger als Linq to SQL (") L2S "). Ab der Veröffentlichung von .NET 4.0 halte ich Linq to SQL für eine veraltete Technologie. MS war sehr offen dafür, die L2S-Entwicklung nicht weiter fortzusetzen.

1) Leistung

Dies ist schwierig zu beantworten. Bei den meisten Single-Entity-Operationen ( CRUD ) ist die Leistung aller drei Technologien nahezu gleich. Sie müssen wissen, wie EF und Linq to SQL funktionieren, um sie optimal nutzen zu können. Bei großvolumigen Vorgängen wie Abfrageabfragen möchten Sie möglicherweise, dass EF / L2S Ihre Entitätsabfrage so "kompiliert", dass das Framework SQL nicht ständig neu generieren muss, oder dass Probleme mit der Skalierbarkeit auftreten können. (siehe Änderungen)

Bei Massenaktualisierungen, bei denen Sie große Datenmengen aktualisieren, ist Roh-SQL oder eine gespeicherte Prozedur immer leistungsfähiger als eine ORM-Lösung, da Sie die Daten nicht über die Leitung zum ORM marshallen müssen, um Aktualisierungen durchzuführen.

2) Entwicklungsgeschwindigkeit

In den meisten Szenarien wird EF nackte SQL / gespeicherte Prozesse in Bezug auf die Entwicklungsgeschwindigkeit umhauen. Der EF-Designer kann Ihr Modell aus Ihrer Datenbank aktualisieren, wenn es sich ändert (auf Anfrage), sodass Sie nicht auf Synchronisierungsprobleme zwischen Ihrem Objektcode und Ihrem Datenbankcode stoßen. Das einzige Mal, dass ich die Verwendung eines ORM nicht in Betracht ziehen würde, ist, wenn Sie eine Anwendung vom Typ Berichterstellung / Dashboard ausführen, in der Sie keine Aktualisierungen durchführen, oder wenn Sie eine Anwendung erstellen, um nur Rohdatenwartungsvorgänge für eine Datenbank durchzuführen.

3) Ordentlicher / wartbarer Code

Zweifellos schlägt EF SQL / Sprocs. Da Ihre Beziehungen modelliert sind, sind Verknüpfungen in Ihrem Code relativ selten. Die Beziehungen der Entitäten sind für den Leser bei den meisten Abfragen fast selbstverständlich. Nichts ist schlimmer, als von Schicht zu Schicht Debugging oder durch mehrere SQL / Middle Tier gehen zu müssen, um zu verstehen, was tatsächlich mit Ihren Daten passiert. EF bringt Ihr Datenmodell auf sehr leistungsstarke Weise in Ihren Code.

4) Flexibilität

Gespeicherte Prozesse und unformatiertes SQL sind "flexibler". Sie können Sprocs und SQL nutzen, um schnellere Abfragen für den jeweiligen Fall zu generieren, und Sie können native DB-Funktionen einfacher als mit und ORM nutzen.

5) Insgesamt

Lassen Sie sich nicht in die falsche Zweiteilung bei der Auswahl eines ORM oder der Verwendung gespeicherter Prozeduren verwickeln. Sie können beide in derselben Anwendung verwenden, und Sie sollten es wahrscheinlich tun. Big-Bulk-Operationen sollten in gespeicherten Prozeduren oder SQL (die tatsächlich von der EF aufgerufen werden können) ausgeführt werden, und EF sollte für Ihre CRUD-Operationen und die meisten Anforderungen Ihrer mittleren Ebene verwendet werden. Vielleicht möchten Sie SQL zum Schreiben Ihrer Berichte verwenden. Ich denke, die Moral der Geschichte ist die gleiche wie immer. Verwenden Sie das richtige Werkzeug für den Job. Aber das Dünne daran ist, dass EF heutzutage sehr gut ist (ab .NET 4.0). Wenn Sie es in Echtzeit lesen und gründlich verstehen, können Sie mühelos erstaunliche, leistungsstarke Apps erstellen.

BEARBEITEN : EF 5 vereinfacht diesen Teil ein wenig mit automatisch kompilierten LINQ-Abfragen , aber für wirklich hochvolumige Inhalte müssen Sie auf jeden Fall testen und analysieren, was in der realen Welt am besten zu Ihnen passt.

Gespeicherte Prozeduren:

(+)

• Große Flexibilität
• Volle Kontrolle über SQL
• Die höchste verfügbare Leistung

(-)

• Erfordert SQL-Kenntnisse
• Gespeicherte Prozeduren befinden sich außerhalb der Quellcodeverwaltung
• Erhebliche Menge an "Wiederholen" bei Angabe derselben Tabellen- und Feldnamen. Die hohe Wahrscheinlichkeit, dass die Anwendung nach dem Umbenennen einer DB-Entität beschädigt wird und irgendwo Verweise darauf fehlen.
• Langsame Entwicklung

ORM:

(+)

• Schnelle Entwicklung
• Datenzugriffscode jetzt unter Quellcodeverwaltung
• Sie sind von Änderungen in der Datenbank isoliert. In diesem Fall müssen Sie Ihr Modell / Ihre Zuordnungen nur an einer Stelle aktualisieren.

(-)

• Die Leistung kann schlechter sein
• Keine oder nur geringe Kontrolle über SQL, das der ORM erzeugt (könnte ineffizient oder schlimmer fehlerhaft sein). Möglicherweise muss eingegriffen und durch benutzerdefinierte gespeicherte Prozeduren ersetzt werden. Dadurch wird Ihr Code unübersichtlich (einige LINQ im Code, einige SQL im Code und / oder in der Datenbank außerhalb der Quellcodeverwaltung).
• Da jede Abstraktion "hochrangige" Entwickler hervorbringen kann, die keine Ahnung haben, wie es unter der Haube funktioniert

Der allgemeine Kompromiss besteht darin, eine große Flexibilität zu haben und viel Zeit zu verlieren, anstatt eingeschränkt zu sein, was Sie tun können, aber es sehr schnell erledigen zu lassen.

Es gibt keine allgemeine Antwort auf diese Frage. Es geht um heilige Kriege. Hängt auch von einem Projekt und Ihren Bedürfnissen ab. Finden Sie heraus, was für Sie am besten funktioniert.

Ihre Frage ist im Grunde O / RM gegen Handschrift SQL

Verwenden Sie ein ORM oder einfaches SQL?

Schauen Sie sich einige der anderen O / RM-Lösungen an, L2S ist nicht die einzige (NHibernate, ActiveRecord).

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

um die spezifischen Fragen zu beantworten:

1. Abhängig von der Qualität der O / RM-Lösung kann L2S ziemlich gut SQL generieren
2. Dies ist normalerweise viel schneller mit einem O / RM, sobald Sie den Prozess durchgeführt haben
3. Code ist normalerweise auch viel ordentlicher und wartbarer
4. Straight SQL bietet Ihnen natürlich mehr Flexibilität, aber die meisten O / RMs können alle bis auf die kompliziertesten Abfragen ausführen
5. Insgesamt würde ich vorschlagen, mit einem O / RM zu gehen, der Flexibilitätsverlust ist vernachlässigbar

LINQ-to-SQL ist eine bemerkenswerte Technologie, die sehr einfach zu verwenden ist und im Großen und Ganzen sehr gute Abfragen an das Back-End generiert. LINQ-to-EF sollte es ersetzen, war jedoch in der Vergangenheit äußerst umständlich zu verwenden und erzeugte weitaus minderwertiges SQL. Ich kenne den aktuellen Stand der Dinge nicht, aber Microsoft hat versprochen, alle Vorteile von L2S in L2EF zu migrieren. Vielleicht ist jetzt alles besser.

Persönlich habe ich eine leidenschaftliche Abneigung gegen ORM-Tools ( Einzelheiten finden Sie in meiner Diatribe hier ), und daher sehe ich keinen Grund, L2EF zu bevorzugen, da L2S mir alles bietet, was ich jemals von einer Datenzugriffsschicht erwarten würde. Ich denke sogar, dass L2S-Funktionen wie handgefertigte Zuordnungen und Vererbungsmodellierung eine völlig unnötige Komplexität verursachen. Aber das bin nur ich. ;-);

Es gibt einen völlig neuen Ansatz, den Sie möglicherweise in Betracht ziehen sollten, wenn Sie nach der Leistung und Leistung gespeicherter Prozeduren und der schnellen Entwicklung suchen, die Tools wie Entity Framework bieten.

Ich habe SQL + für eine Probefahrt in einem kleinen Projekt genommen, und es ist wirklich etwas Besonderes. Grundsätzlich fügen Sie Ihren SQL-Routinen Kommentare hinzu, und diese Kommentare enthalten Anweisungen für einen Codegenerator, der dann eine wirklich schöne objektorientierte Klassenbibliothek auf der Grundlage der tatsächlichen SQL-Routine erstellt. Ein bisschen wie ein Entity Framework in umgekehrter Richtung.

Eingabeparameter werden Teil eines Eingabeobjekts, Ausgabeparameter und Ergebnismengen werden Teil eines Ausgabeobjekts, und eine Servicekomponente stellt die Methodenaufrufe bereit.

Wenn Sie gespeicherte Prozeduren verwenden möchten, aber dennoch eine schnelle Entwicklung wünschen, sollten Sie sich dieses Material ansehen.