Entity Framework Gespeicherte Prozeduren vs Generierte SQL

Ich habe das entity framework in ein paar Projekten. In jedem Projekt habe ich verwendet, die gespeicherten Prozeduren zugeordnet, die Personen wegen der bekannten Vorteile von gespeicherten Prozeduren - Sicherheit, Wartbarkeit, etc. Allerdings, 99% der gespeicherten Prozeduren sind grundlegende CRUD-Prozeduren. Dies scheint, wie es unterschlägt eines der wesentlichen, zeitsparenden Funktionen der Entity Framework-SQL-generation.

Ich gelesen habe, einige der Argumente in Bezug auf gespeicherte Prozeduren vs. generierte SQL von Entity Framework. Während der Verwendung von CRUD-SPs ist besser für die Sicherheit, und die generierte SQL von EF ist oft komplexer als nötig, ist es wirklich alles zu kaufen in Bezug auf die performance oder Wartbarkeit zu verwenden SPs?

Hier ist, was ich glaube:

  • Die meisten der Zeit, ändern eines SP erfordert die Aktualisierung des Datenmodells
    sowieso. Also, es ist nicht Kauf viel in Bezug auf die Wartbarkeit.
  • Für web-Anwendungen, die Verbindung mit der Datenbank verwendet eine einzelne Benutzer-ID spezifisch für die Anwendung. So, Benutzer haben nicht einmal direkte Zugriff auf die Datenbank. Das reduziert die Sicherheit profitieren.
  • Für eine kleine Anwendung, die leicht verringerte Leistung von über
    generiert SQL würde wahrscheinlich nicht viel von einem Problem. Für hohen
    Lautstärke, performance-kritische Anwendungen, würde die EF auch ein weiser sein
    Wahl? Plus, sind die insert - /update - /delete-Anweisungen generiert
    von EF wirklich so schlecht?
  • Senden jedes Attribut an eine gespeicherte Prozedur ist es, die eigene Leistung Strafen, in der Erwägung, dass die EF-generierten code sendet nur die Attribute, die auch wirklich geändert wurden. Wenn dabei die updates zu große Tabellen, die den Netzwerkverkehr erhöht und den Aufwand für die Aktualisierung aller Attribute wahrscheinlich negiert die Leistung von gespeicherten Prozeduren.

Mit dieser sagte, meine konkreten Fragen sind:

Sind meine überzeugungen, die oben aufgeführt sind, korrekt? Die Idee ist, immer mit SPs etwas, das ist "old school" nun, dass ORMs sind an Popularität gewinnt? In Ihrer Erfahrung, das ist der bessere Weg zu gehen mit EF-Abbildung SPs für alle insert /update /deletes, oder mit EF-generierten SQL-Code für die CRUD-Operationen und nur mit SPs für komplexere Sachen?

modifying an SP requires updating the data model anyway SP ' s am Ende deutlich erhöhen die Kosten für die Wartung Ihrer Anwendung, nicht nur, weil Sie jede Veränderung in mindestens 5 stellen (1 SP für jede insert -, update, und löschen Sie mindestens eine auswählen, und dann auch in Ihrer Entität-Modell), sondern auch, weil für alles, was nicht eine einfache CRUD-operation, die Sie sich verstecken Anwendungslogik außerhalb der Anwendung, der Entwickler hat zu hüpfen hin und her zwischen verschiedenen IDE.

InformationsquelleAutor DCNYAM | 2011-07-22

  1. 34

    Ich denke immer mit SP ' s ist etwas old school. Ich verwendet, um code auf diese Weise, und nun alles tun, was ich kann EF-generierten code...und wenn ich ein performance-problem, oder andere Sonderzeichen müssen in, ich fügen Sie zurück in eine strategische SP um ein bestimmtes problem lösen....es muss nicht entweder oder - beides verwenden.

    Alle meine grundlegende CRUD-Operationen sind die geraden EF-generierten code - meine web-apps verwendet werden, um 100 oder mehr SP 's, jetzt ein typischer, wird man ein Dutzend SP' s und alles andere ist fertig in meinem C# - code....und meine Produktivität hat gegangen WEG von Beseitigung diese 95% der CRUD-gespeicherte Prozeduren.

    +1 ein guter, pragmatischer Ansatz - dann würde ich wahrscheinlich diesen Weg gehen, auch. Nutzung EF so viel wie möglich, aber mit dem wissen, dass wenn Sie brauchen, um zu optimieren, den letzten Tropfen Leistung aus einem INSERT Aussage irgendwo, das können Sie, indem Sie eine gespeicherte Prozedur für Sie.
    Wie Sie gesagt wegen dem performance-Problem, es ist wirklich Wert zu schreiben, ein SP, aber wie über die Verwendung von Ansichten (natürlich statt einer select-Abfrage in SP)? Ich konnte nicht finden alles rund um den Vergleich zwischen diesen beiden Ansätzen.

    InformationsquelleAutor E.J. Brennan

  2. 12

    Ja, deine überzeugungen sind absolut korrekt. Verwendung von gespeicherten Prozeduren für die Daten-manipulation hat eine Bedeutung, vor allem, wenn:

    • Datenbank folgt strengen Sicherheits-Regeln, wo das ändern von Daten zulässig ist nur über gespeicherte Prozeduren
    • Sie Ansichten verwenden oder benutzerdefinierte Abfragen für die Zuordnung der Entitäten und müssen Sie advanced logic in stored procedure push-Daten zurück
    • Sie haben einige erweiterte Logik (in Bezug auf Daten) in das Verfahren aus einem anderen Grund

    Mithilfe von Verfahren für Reine CUD, wo nicht genannten Fälle gilt, ist überflüssig und es nicht zu messbaren performance-Schub, außer einzelne Szenario

    • Verwenden Sie gespeicherte Prozeduren für batch /bulk-änderungen

    EF nicht bulk /batch-Funktionalität so ändern 1000 Datensätze Ergebnis in 1000 updates jede ausgeführte mit separaten Datenbank-Rundreise! Aber solche Verfahren nicht zugeordnet werden können, um Entitäten und sowieso ausgeführt werden muss GESONDERT über die Funktion importieren (wenn möglich) oder direkt als ExecuteStoreCommand oder alt ADO.NET (zum Beispiel, wenn Sie verwenden möchten, table-valued Parameters).

    Der ganze andere Geschichte sein kann, R CRUD, wo die gespeicherte Prozedur können erhebliche performance-boost für das Lesen von Daten mit Ihren eigenen optimierten Abfragen.

    InformationsquelleAutor Ladislav Mrnka

  3. 6

    Wenn Leistung ist Ihr primäres Anliegen ist, dann sollten Sie eine der vorhandenen apps, nutzt EF mit SPs, deaktivieren Sie die SPs-und benchmark in der neuen version. Das ist der einzige Weg, um eine Antwort zu bekommen, die perfekt auf Ihre situation zutrifft. Sie werden möglicherweise feststellen, dass EF keine Rolle, was Sie tun, nicht schnell genug für Ihre performance-Anforderungen im Vergleich zu den benutzerdefinierten code, aber außerhalb der sehr hohe Lautstärke Websites, die ich denke, EF 4.1 ist eigentlich ziemlich vernünftig.

    Aus meiner PoV, EF ist eine große Produktivität der Entwickler zu steigern. Sie verlieren einiges, wenn du schreibst SPs für einfache CRUD-Operationen, und für Insert/Update/Delete in allem, was ich sehe wirklich nicht, gewinnt Ihr viel in der Leistung, weil diese Operationen so einfach zu generieren SQL für. Es gibt definitiv einige ausgewählte Fälle, in denen EF nicht die optimale Sache, und Sie können große Leistung erhöht, indem eine SP (hierarchische Abfragen mit CONNECT BY in Oracle kommen in den Sinn als ein Beispiel).

    Der beste Weg, um den Umgang mit dieser Art der Sache ist, schreiben Sie Ihre app Vermietung EF-SQL generieren. Benchmark-it. Finden Sie Bereiche, wo es performance-Probleme und schreiben von SPs für diejenigen. Löschen ist fast nie zu einer von den Fällen, die Sie benötigen, um dies zu tun.

    Wie Sie bereits erwähnt, die Sicherheit gewinnen, hier ist etwas verringert, weil man EF auf einer Anwendungsebene, die hat ein eigenes Konto für die app sowieso, so dass Sie einschränken können, was es tut. SPs-geben Sie ein wenig mehr Kontrolle, aber in der typischen Anwendung, ich glaube nicht, dass es darauf ankommt.

    Es ist eine interessante Frage, die keinen wirklich richtigen oder falschen Antworten. Ich benutze in Erster Linie EF, so dass ich nicht schreiben generisches CRUD-SPs und kann stattdessen verbringe meine Zeit mit arbeiten auf komplexere Fälle, so für mich würde ich sagen, Sie sollten schreiben weniger von Ihnen. 🙂

    InformationsquelleAutor Tridus

  4. 1

    Ich Stimme weitgehend mit E. J, aber es gibt ein paar andere Optionen. Es ist wirklich darauf an, die Anforderungen für das jeweilige system:

    • Brauchen Sie, um die app entwickelte sich SCHNELL? - Dann nutzen Sie entity framework und seine automatische SQL
    • Müssen feinkörnigen und festen Sicherheit? - Auf gespeicherte Prozeduren
    • Es brauchen, um so schnell wie möglich? - Sie sind wahrscheinlich auf der Suche an etwas glückliches medium!

    InformationsquelleAutor Chris Surfleet

  5. 0

    Meiner Meinung nach so lange, wie Sie Ihre Anwendung/Datenbank nicht leiden performance-Probleme und Sie sind meist unter Verwendung der Datenbank für den CRUD-Zugriff mit nur einem DB-user, es ist besser zu nutzen, generierte SQL. Es ist schneller zu entwickeln, besser zu warten und die wenigen, die Sicherheit oder die Privatsphäre Vorteile, die es nicht Wert sind (wenn die Daten nicht so empfindlich). Auch der Einsatz von Modell-basierten Datenbank-Zugriff oder LINQ deaktiviert die Gefahr von SQL-injections.

    InformationsquelleAutor gw0

Schreibe einen Kommentar