it-swarm.com.de

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

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

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

Ich mag mein SQL und war daher 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-Schicht herausgeschrieben habe und beschlossen habe, sie auszugeben einige Zeit wirklich verstehen entweder Linq zu SQL oder EF ... oder keine?

Ich möchte nur prüfen, dass bei keiner dieser Technologien ein großer Fehler vorliegt, der meine Forschungszeit unbrauchbar machen würde. Z.B. Die Leistung ist schrecklich, es 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. EF VS L2S interessiert mich hauptsächlich. Aber ich bin sehr daran interessiert, sie auch mit gespeicherten Prozessen abgleichen zu lassen, da SQl einfach etwas ist, über das ich viel weiß.

413

Wenn Sie ein neues Projekt beginnen, sollten Sie sich zunächst für Entity Framework ("EF") entscheiden. Es generiert jetzt viel bessere SQL-Werte (mehr wie Linq to SQL) und ist einfacher zu warten und leistungsfähiger als Linq to SQL (" L2S "). Seit der Veröffentlichung von .NET 4.0 halte ich Linq to SQL für eine veraltete Technologie. MS war sehr offen darüber, die L2S-Entwicklung nicht fortzusetzen.

1) Leistung

Das ist schwierig zu beantworten. Für die meisten Single-Entity-Operationen ( CRUD ) werden Sie bei allen drei Technologien eine nahezu gleichwertige Leistung finden. Sie müssen wissen, wie EF und Linq to SQL funktionieren, um sie optimal nutzen zu können. Für umfangreiche Vorgänge wie Abfrageabfragen möchten Sie möglicherweise, dass EF/L2S Ihre Entitätsabfrage "kompiliert", sodass das Framework die SQL nicht ständig neu generieren muss oder dass Probleme mit der Skalierbarkeit auftreten. (siehe Änderungen)

Bei Massenaktualisierungen, bei denen Sie große Datenmengen aktualisieren, ist Raw SQL oder eine gespeicherte Prozedur immer besser als eine ORM-Lösung, da Sie die Daten nicht über das Kabel an den ORM übergeben müssen, um Aktualisierungen durchzuführen. 

2) Entwicklungsgeschwindigkeit

In den meisten Szenarien wird EF nackte SQL/gespeicherte Prozeduren wegblasen, wenn es um die Entwicklungsgeschwindigkeit geht. Der EF-Designer kann Ihr Modell von Ihrer Datenbank aus aktualisieren, wenn es geändert wird (auf Anfrage), sodass keine Synchronisierungsprobleme zwischen Ihrem Objektcode und Ihrem Datenbankcode auftreten. Der einzige Zeitpunkt, an den ich keinen ORM verwenden würde, ist, wenn Sie eine Anwendung für das Reporting/Dashboard-Typ ausführen, bei der Sie keine Aktualisierungen durchführen, oder wenn Sie eine Anwendung erstellen, die lediglich Rohdatenverwaltungsvorgänge für eine Datenbank ausführt. 

3) Ordentlicher/wartbarer Code

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

4) Flexibilität

Gespeicherte Prozeduren und Raw SQL sind "flexibler". Sie können Sprocs und SQL nutzen, um schnellere Abfragen für den ungeraden spezifischen Fall zu generieren, und Sie können die native DB-Funktionalität einfacher als mit ORM nutzen. 

5) Insgesamt 

Lassen Sie sich nicht von der falschen Dichotomie der Wahl eines ORM im Vergleich zu gespeicherten Prozeduren verwickeln. Sie können beide in derselben Anwendung verwenden, was Sie wahrscheinlich sollten. Große Massenoperationen sollten in gespeicherten Prozeduren oder SQL (die tatsächlich von der EF aufgerufen werden können) verwendet werden, und EF sollte für Ihre CRUD-Operationen und die meisten Anforderungen Ihrer mittleren Schicht verwendet werden. Vielleicht möchten Sie SQL zum Schreiben Ihrer Berichte verwenden. Ich denke, die Moral der Geschichte ist dieselbe wie immer. Verwenden Sie das richtige Werkzeug für den Job. Aber das Mager ist, EF ist heutzutage sehr gut (ab .NET 4.0). Lesen Sie in Echtzeit und verstehen Sie es gründlich, und Sie können mit Leichtigkeit erstaunliche Hochleistungs-Apps erstellen.

EDIT: EF 5 vereinfacht diesen Teil mit automatisch kompilierten LINQ-Abfragen , aber für echtes High Volume-Material müssen Sie auf jeden Fall testen und analysieren, was am besten zu Ihnen passt Welt.

421
Dave Markle

Gespeicherte Prozeduren:

(++)

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

(-)

  • Erfordert Kenntnisse in SQL
  • Gespeicherte Prozeduren befinden sich außerhalb der Quellcodeverwaltung
  • Erhebliche Menge an "Wiederholen" bei Angabe derselben Tabellen- und Feldnamen. Die hohe Wahrscheinlichkeit, dass die Anwendung beschädigt wird, nachdem eine DB-Entität umbenannt wurde und einige 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 lediglich das Modell/die Zuordnungen an einer Stelle aktualisieren.

(-)

  • Leistung kann schlechter sein
  • Keine oder nur eine geringe Kontrolle über das ORM (möglicherweise ineffizient oder schlimmer). Möglicherweise müssen Sie eingreifen und durch benutzerdefinierte gespeicherte Prozeduren ersetzen. Dadurch wird Ihr Code unübersichtlich (einige LINQ-Codes, einige SQL-Codes und/oder die DB befinden sich außerhalb der Quellcodeverwaltung).
  • Da jede Abstraktion "hochrangige" Entwickler hervorbringen kann, die keine Ahnung haben, wie es unter der Haube funktioniert

Der generelle Kompromiss besteht darin, eine große Flexibilität zu haben und viel Zeit zu verlieren, im Hinblick auf das, was man tun kann, eingeschränkt zu sein, aber es sehr schnell erledigt zu sein.

Auf diese Frage gibt es keine allgemeine Antwort. Es ist eine Sache der heiligen Kriege. Kommt auch auf ein Projekt und Ihre Bedürfnisse an. Heben Sie auf, was für Sie am besten funktioniert.

89
user151323

ihre Frage ist im Wesentlichen O/RMs vs Handschrift-SQL

Mit einem ORM oder normalem SQL?

Werfen Sie einen Blick auf die anderen O/RM-Lösungen, 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 SQL sehr gut generieren
  2. Dies ist normalerweise mit einem O/RM viel schneller, wenn Sie den Prozess grokken
  3. Code ist normalerweise auch viel übersichtlicher und wartungsfreundlicher
  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
18
BlackICE

LINQ-to-SQL ist eine bemerkenswerte Technologie, die sehr einfach zu bedienen ist und im Großen und Ganzen sehr gute Abfragen an das Back-End generiert. LINQ-to-EF sollte es ablösen, war aber in der Vergangenheit äußerst unübersichtlich und generierte weitaus minderwertige SQL. Ich kenne den aktuellen Stand der Dinge nicht, aber Microsoft hat versprochen, alles Gute von L2S in L2EF zu migrieren. Vielleicht ist es jetzt alles besser.

Ich persönlich habe eine leidenschaftliche Abneigung gegen ORM-Tools (siehe meine Diatribe hier für Details), und daher sehe ich keinen Grund, L2EF zu bevorzugen, da L2S mir alles bietet, was ich von einer Datenzugriffsschicht erwartet. Ich denke sogar, dass L2S-Funktionen wie handgefertigte Mappings und Vererbungsmodelle völlig unnötige Komplexität hinzufügen. Aber das ist nur ich. ;-)

13
Marcelo Cantos

Es gibt einen völlig neuen Ansatz, den Sie in Betracht ziehen sollten, wenn Sie die Leistungsfähigkeit und Leistung von gespeicherten Prozeduren und die schnelle Entwicklung von Tools wie Entity Framework erwarten.

Ich habe SQL + für eine kleine Probefahrt genommen, und es ist wirklich etwas Besonderes. Sie fügen Ihren SQL-Routinen im Wesentlichen die Anzahl der Kommentare hinzu. Diese Kommentare enthalten Anweisungen für einen Codegenerator, der dann eine auf Nice basierende objektorientierte Klassenbibliothek auf der Grundlage der tatsächlichen SQL-Routine erstellt. Eine Art ähnliches 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 diese Informationen ansehen.

0
Vincent