LINQ-to-SQL gegen gespeicherte Prozeduren? [geschlossen]

Ich habe mir den Beitrag "Anfängerleitfaden zu LINQ" hier auf StackOverflow ( Anfängerleitfaden zu LINQ ) angesehen, hatte aber eine Folgefrage:

Wir sind dabei, ein neues Projekt hochzufahren, bei dem fast alle unserer Datenbankoperationen relativ einfache Datenabrufe sein werden (es gibt ein anderes Segment des Projekts, das die Daten bereits schreibt). Die meisten unserer bisherigen Projekte verwenden für solche Dinge gespeicherte Prozeduren. Ich möchte jedoch LINQ-to-SQL nutzen, wenn es sinnvoller ist.

Die Frage lautet also: Welcher Ansatz ist für einfache Datenabrufe besser, LINQ-to-SQL oder gespeicherte Prozesse? Irgendwelche spezifischen Vor- oder Nachteile?

Vielen Dank.

Einige Vorteile von LINQ gegenüber Sprocs:

1. Typensicherheit : Ich denke, wir alle verstehen das.
2. Abstraktion : Dies gilt insbesondere für LINQ-to-Entities . Diese Abstraktion ermöglicht es dem Framework auch, zusätzliche Verbesserungen hinzuzufügen, die Sie leicht nutzen können. PLINQ ist ein Beispiel für das Hinzufügen von Multithreading-Unterstützung zu LINQ. Codeänderungen sind minimal, um diese Unterstützung hinzuzufügen. Es wäre VIEL schwieriger, diesen Datenzugriffscode zu erstellen, der einfach Sprocs aufruft.
3. Debugging-Unterstützung : Ich kann jeden .NET-Debugger zum Debuggen der Abfragen verwenden. Mit Sprocs können Sie SQL nicht einfach debuggen, und diese Erfahrung hängt weitgehend von Ihrem Datenbankanbieter ab (MS SQL Server bietet einen Abfrageanalysator, dies reicht jedoch häufig nicht aus).
4. Herstellerunabhängig : LINQ arbeitet mit vielen Datenbanken und die Anzahl der unterstützten Datenbanken wird nur zunehmen. Sprocs sind nicht immer zwischen Datenbanken portierbar, entweder aufgrund unterschiedlicher Syntax oder Funktionsunterstützung (wenn die Datenbank überhaupt Sprocs unterstützt).
5. Bereitstellung : Andere haben dies bereits erwähnt, aber es ist einfacher, eine einzelne Assembly bereitzustellen, als eine Reihe von Sprocs bereitzustellen. Dies knüpft auch an # 4 an.
6. Einfacher : Sie müssen weder T-SQL für den Datenzugriff noch die für den Aufruf der Sprocs erforderliche Datenzugriffs-API (z. B. ADO.NET) erlernen. Dies hängt mit # 3 und # 4 zusammen.

Einige Nachteile von LINQ gegenüber Sprocs:

1. Netzwerkverkehr : Sprocs müssen nur Sproc-Namen- und Argumentdaten über die Leitung serialisieren, während LINQ die gesamte Abfrage sendet. Dies kann sehr schlimm werden, wenn die Abfragen sehr komplex sind. Die Abstraktion von LINQ ermöglicht es Microsoft jedoch, dies im Laufe der Zeit zu verbessern.
2. Weniger flexibel : Sprocs können das Feature-Set einer Datenbank voll ausnutzen. LINQ ist in seiner Unterstützung eher allgemein gehalten. Dies ist bei jeder Art von Sprachabstraktion üblich (z. B. C # vs Assembler).
3. Neukompilieren : Wenn Sie Änderungen an der Art und Weise des Datenzugriffs vornehmen müssen, müssen Sie Ihre Assembly neu kompilieren, versionieren und erneut bereitstellen. Mit Sprocs kann ein DBA manchmal die Datenzugriffsroutine optimieren, ohne dass eine erneute Bereitstellung erforderlich ist .

Sicherheit und Verwaltbarkeit sind etwas, worüber sich die Leute auch streiten.

1. Sicherheit : Sie können beispielsweise Ihre vertraulichen Daten schützen, indem Sie den Zugriff auf die Tabellen direkt einschränken und ACLs auf die Sprocs setzen. Mit LINQ, Sie können jedoch nach wie vor den direkten Zugriff auf Tabellen beschränken und stattdessen setzen ACLs auf aktualisierbaren Tabelle Ansichten ein ähnliches Ziel zu erreichen (vorausgesetzt , Ihre Datenbank unterstützt aktualisierbaren Sichten).
2. Verwaltbarkeit : Die Verwendung von Ansichten bietet Ihnen auch den Vorteil, dass Ihre Anwendung nicht vor Schemaänderungen geschützt wird (z. B. Tabellennormalisierung). Sie können die Ansicht aktualisieren, ohne dass sich Ihr Datenzugriffscode ändern muss.

Früher war ich ein großer Sproc-Typ, aber ich fange an, mich für LINQ als bessere Alternative im Allgemeinen zu interessieren. Wenn es Bereiche gibt, in denen Sprocs deutlich besser sind, schreibe ich wahrscheinlich immer noch einen Sproc, greife aber mit LINQ darauf zu. :) :)

Ich bin im Allgemeinen ein Befürworter, alles in gespeicherte Prozeduren zu stecken, aus all den Gründen, aus denen DBAs seit Jahren arbeiten. Im Fall von Linq gibt es zwar keinen Leistungsunterschied bei einfachen CRUD-Abfragen.

Beachten Sie jedoch einige Dinge, wenn Sie diese Entscheidung treffen: Wenn Sie ein ORM verwenden, sind Sie eng mit Ihrem Datenmodell verbunden. Ein DBA hat keine Freiheit, Änderungen am Datenmodell vorzunehmen, ohne dass Sie gezwungen sind, Ihren kompilierten Code zu ändern. Mit gespeicherten Prozeduren können Sie diese Art von Änderungen bis zu einem gewissen Grad ausblenden, da die von einer Prozedur zurückgegebene Parameterliste und die Ergebnismenge (n) ihren Vertrag darstellen und die Innereien geändert werden können, solange dieser Vertrag noch erfüllt ist .

Wenn Linq für komplexere Abfragen verwendet wird, wird das Optimieren der Datenbank zu einer viel schwierigeren Aufgabe. Wenn eine gespeicherte Prozedur langsam ausgeführt wird, kann sich der DBA vollständig auf den Code konzentrieren und verfügt über viele Optionen, sodass der Vertrag nach Abschluss des Vorgangs immer noch erfüllt ist.

Ich habe viele, viele Fälle gesehen, in denen schwerwiegende Probleme in einer Anwendung durch Änderungen am Schema und am Code in gespeicherten Prozeduren behoben wurden, ohne dass Änderungen am bereitgestellten, kompilierten Code vorgenommen wurden.

Vielleicht wäre ein Hybird-Ansatz mit Linq schön? Mit Linq können natürlich gespeicherte Prozeduren aufgerufen werden.

Linq zu Sql.

Der SQL Server speichert die Abfragepläne im Cache, sodass für Sprocs kein Leistungsgewinn erzielt wird.

Andererseits werden Ihre linq-Anweisungen logisch Teil Ihrer Anwendung sein und mit dieser getestet. Sprocs sind immer etwas voneinander getrennt und schwerer zu warten und zu testen.

Wenn ich jetzt von Grund auf an einer neuen Anwendung arbeiten würde, würde ich nur Linq verwenden, keine Sprocs.

Für das Abrufen grundlegender Daten würde ich ohne zu zögern Linq wählen.

Seit meinem Wechsel zu Linq habe ich folgende Vorteile festgestellt:

1. Das Debuggen meines DAL war noch nie einfacher.
2. Die Kompilierungszeitsicherheit bei Änderungen Ihres Schemas ist von unschätzbarem Wert.
3. Die Bereitstellung ist einfacher, da alles in DLLs kompiliert ist. Keine Verwaltung von Bereitstellungsskripten mehr.
4. Da Linq das Abfragen von Elementen unterstützt, die die IQueryable-Schnittstelle implementieren, können Sie dieselbe Syntax zum Abfragen von XML, Objekten und anderen Datenquellen verwenden, ohne eine neue Syntax erlernen zu müssen

LINQ wird den Prozedur-Cache aufblähen

Wenn eine Anwendung LINQ to SQL verwendet und die Abfragen die Verwendung von Zeichenfolgen beinhalten, deren Länge sehr unterschiedlich sein kann, wird der SQL Server-Prozedurcache mit einer Version der Abfrage für jede mögliche Zeichenfolgenlänge aufgebläht. Betrachten Sie beispielsweise die folgenden sehr einfachen Abfragen, die für die Person.AddressTypes-Tabelle in der AdventureWorks2008-Datenbank erstellt wurden:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Wenn diese beiden Abfragen ausgeführt werden, werden zwei Einträge im SQL Server-Prozedurcache angezeigt: Einer mit einem NVARCHAR (7) und der andere mit einem NVARCHAR (11). Stellen Sie sich nun vor, es gäbe Hunderte oder Tausende verschiedener Eingabezeichenfolgen mit unterschiedlichen Längen. Der Prozedur-Cache würde unnötigerweise mit allen möglichen Plänen für genau dieselbe Abfrage gefüllt.

Mehr hier: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Ich denke, das Pro-LINQ-Argument scheint von Leuten zu kommen, die (im Allgemeinen) keine Geschichte mit Datenbankentwicklung haben.

Insbesondere bei Verwendung eines Produkts wie VS DB Pro oder Team Suite gelten viele der hier vorgebrachten Argumente nicht, z.

Schwieriger zu warten und zu testen: VS bietet vollständige Syntaxprüfung, Stilprüfung, Referenz- und Einschränkungsprüfung und mehr. Es bietet auch umfassende Unit-Test-Funktionen und Refactoring-Tools.

LINQ macht echte Unit-Tests unmöglich, da es (meiner Meinung nach) den ACID-Test nicht besteht.

Das Debuggen ist in LINQ einfacher: Warum? VS ermöglicht den vollständigen Einstieg in verwalteten Code und das regelmäßige Debuggen von SPs.

In eine einzige DLL kompiliert und nicht in Bereitstellungsskripten: Erneut hilft VS, vollständige Datenbanken zu erstellen und bereitzustellen oder datensichere inkrementelle Änderungen vorzunehmen.

Sie müssen TSQL nicht mit LINQ lernen: Nein, das tun Sie nicht, aber Sie müssen LINQ lernen - wo ist der Vorteil?

Ich sehe das wirklich nicht als Vorteil. In der Lage zu sein, etwas isoliert zu ändern, mag theoretisch gut klingen, aber nur weil die Änderungen einen Vertrag erfüllen, heißt das nicht, dass sie die richtigen Ergebnisse liefern. Um feststellen zu können, welche Ergebnisse korrekt sind, benötigen Sie einen Kontext, den Sie aus dem aufrufenden Code abrufen.

Ähm, lose gekoppelte Apps sind das ultimative Ziel aller guten Programmierer, da sie die Flexibilität wirklich erhöhen. Es ist fantastisch, Dinge isoliert ändern zu können, und es sind Ihre Unit-Tests, die sicherstellen, dass immer noch angemessene Ergebnisse erzielt werden.

Bevor Sie sich alle aufregen, denke ich, dass LINQ seinen Platz hat und eine große Zukunft hat. Für komplexe, datenintensive Anwendungen halte ich es jedoch nicht für bereit, gespeicherte Prozeduren zu ersetzen. Dies war eine Ansicht, die ich dieses Jahr von einem MVP bei TechEd bestätigt hatte (sie werden namenlos bleiben).

BEARBEITEN: Die Seite der gespeicherten Prozedur von LINQ zu SQL ist etwas, worüber ich noch mehr lesen muss - je nachdem, was ich finde, kann ich meine obige Diatribe ändern;)

LINQ ist neu und hat seinen Platz. LINQ wurde nicht erfunden, um gespeicherte Prozeduren zu ersetzen.

Hier werde ich mich auf einige Performance-Mythen & CONS konzentrieren, nur für "LINQ to SQL", natürlich könnte ich mich völlig irren ;-)

(1) Die Leute sagen, dass die LINQ-Anweisung in SQL Server "zwischengespeichert" werden kann, damit sie nicht an Leistung verliert. Teilweise wahr. "LINQ to SQL" ist eigentlich die Laufzeit, die die LINQ-Syntax in die TSQL-Anweisung übersetzt. Aus Sicht der Leistung unterscheidet sich eine fest codierte ADO.NET SQL-Anweisung nicht von LINQ.

(2) In einem Beispiel hat eine Kundendienst-Benutzeroberfläche eine "Kontoübertragungs" -Funktion. Diese Funktion selbst aktualisiert möglicherweise 10 DB-Tabellen und gibt einige Nachrichten auf einmal zurück. Mit LINQ müssen Sie eine Reihe von Anweisungen erstellen und diese als einen Stapel an den SQL Server senden. Die Leistung dieses übersetzten LINQ-> TSQL-Batches kann kaum mit der gespeicherten Prozedur mithalten. Grund? Da Sie die kleinste Einheit der Anweisung in der gespeicherten Prozedur mithilfe des integrierten SQL-Profilers und des Ausführungsplan-Tools optimieren können, können Sie dies in LINQ nicht tun.

Der Punkt ist, wenn Sie über eine einzelne DB-Tabelle und einen kleinen Datensatz CRUD sprechen, ist LINQ so schnell wie SP. Für eine viel kompliziertere Logik ist die gespeicherte Prozedur jedoch leistungsoptimierbarer.

(3) "LINQ to SQL" macht Neulinge leicht dazu, Leistungsfresser einzuführen. Jeder ältere TSQL-Typ kann Ihnen sagen, wann Sie CURSOR nicht verwenden sollen (Grundsätzlich sollten Sie CURSOR in TSQL in den meisten Fällen nicht verwenden). Mit LINQ und der charmanten "foreach" -Schleife mit Abfrage ist es für Neulinge so einfach, solchen Code zu schreiben:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Sie können sehen, dass dieser einfache anständige Code so attraktiv ist. Unter der Haube übersetzt die .NET-Laufzeit dies jedoch einfach in einen Update-Stapel. Wenn nur 500 Zeilen vorhanden sind, handelt es sich um einen TSQL-Stapel mit 500 Zeilen. Wenn es Millionen Zeilen gibt, ist dies ein Treffer. Natürlich wird ein erfahrener Benutzer diesen Job nicht verwenden, aber der Punkt ist, dass es so einfach ist, auf diese Weise zu fallen.

Der beste Code ist kein Code, und bei gespeicherten Prozeduren müssen Sie mindestens einen Code in die Datenbank und Code in die Anwendung schreiben, um ihn aufzurufen, während Sie bei LINQ to SQL oder LINQ to Entities keinen zusätzlichen Code schreiben müssen Code, der über jede andere LINQ-Abfrage hinausgeht, abgesehen von der Instanziierung eines Kontextobjekts.

LINQ hat definitiv seinen Platz in anwendungsspezifischen Datenbanken und in kleinen Unternehmen.

In einem großen Unternehmen, in dem zentrale Datenbanken als Drehscheibe für gemeinsame Daten für viele Anwendungen dienen, benötigen wir jedoch eine Abstraktion. Wir müssen die Sicherheit zentral verwalten und Zugriffshistorien anzeigen. Wir müssen in der Lage sein, Auswirkungsanalysen durchzuführen: Wenn ich eine kleine Änderung am Datenmodell vornehme, um neuen Geschäftsanforderungen gerecht zu werden, welche Abfragen müssen geändert und welche Anwendungen müssen erneut getestet werden? Ansichten und gespeicherte Prozeduren geben mir das. Wenn LINQ all das kann und unsere Programmierer produktiver macht, werde ich es begrüßen - hat jemand Erfahrung damit in einer solchen Umgebung?

Ein DBA hat keine Freiheit, Änderungen am Datenmodell vorzunehmen, ohne dass Sie gezwungen sind, Ihren kompilierten Code zu ändern. Mit gespeicherten Prozeduren können Sie diese Art von Änderungen bis zu einem gewissen Grad ausblenden, da die von einer Prozedur zurückgegebene Parameterliste und die Ergebnismenge (n) ihren Vertrag darstellen und die Innereien geändert werden können, solange dieser Vertrag noch erfüllt ist .

Ich sehe das wirklich nicht als Vorteil. In der Lage zu sein, etwas isoliert zu ändern, mag theoretisch gut klingen, aber nur weil die Änderungen einen Vertrag erfüllen, heißt das nicht, dass sie die richtigen Ergebnisse liefern. Um feststellen zu können, welche Ergebnisse korrekt sind, benötigen Sie einen Kontext, den Sie aus dem aufrufenden Code abrufen.

IMHO, RAD = LINQ, RUP = Gespeicherte Prozesse. Ich habe viele Jahre für ein großes Fortune 500-Unternehmen gearbeitet, auf vielen Ebenen, einschließlich des Managements, und ehrlich gesagt würde ich niemals RUP-Entwickler für die RAD-Entwicklung einstellen. Sie sind so dumm, dass sie nur sehr begrenzte Kenntnisse darüber haben, was auf anderen Ebenen des Prozesses zu tun ist. In einer isolierten Umgebung ist es sinnvoll, Datenbankadministratoren die Kontrolle über die Daten über ganz bestimmte Einstiegspunkte zu geben, da andere offen gesagt nicht wissen, wie das Datenmanagement am besten durchgeführt werden kann.

Aber große Unternehmen bewegen sich in der Entwicklungsbranche schmerzhaft langsam, und dies ist äußerst kostspielig. Es gibt Zeiten, in denen Sie sich schneller bewegen müssen, um Zeit und Geld zu sparen, und LINQ bietet dies und mehr in Pik.

Manchmal denke ich, dass DBAs gegen LINQ voreingenommen sind, weil sie das Gefühl haben, dass dies ihre Arbeitsplatzsicherheit gefährdet. Aber das ist die Natur des Tieres, meine Damen und Herren.

Ich denke, Sie müssen mit Procs für alles echte gehen.

A) Wenn Sie Ihre gesamte Logik in linq schreiben, ist Ihre Datenbank weniger nützlich, da nur Ihre Anwendung sie verwenden kann.

B) Ich bin sowieso nicht davon überzeugt, dass Objektmodellierung besser ist als relationale Modellierung.

C) Das Testen und Entwickeln einer gespeicherten Prozedur in SQL ist um einiges schneller als ein Kompilierungsbearbeitungszyklus in einer Visual Studio-Umgebung. Sie bearbeiten einfach F5 und drücken die Auswahltaste und schon können Sie loslegen.

D) Es ist einfacher, gespeicherte Prozeduren zu verwalten und bereitzustellen als Assemblys. Sie legen die Datei einfach auf dem Server ab und drücken F5 ...

E) Linq to SQL schreibt immer noch beschissenen Code zu Zeiten, in denen Sie ihn nicht erwarten.

Ehrlich gesagt denke ich, dass es das ultimative Ziel für MS wäre, t-sql zu erweitern, damit es implizit eine Join-Projektion durchführen kann, wie es linq tut. t-sql sollte beispielsweise wissen, ob Sie order.lineitems.part ausführen möchten.

LINQ verbietet nicht die Verwendung gespeicherter Prozeduren. Ich habe den gemischten Modus mit LINQ-SQL und LINQ-savedproc verwendet . Persönlich bin ich froh, dass ich die gespeicherten Prozesse nicht schreiben muss ... pwet-tu.

Es gibt auch das Problem eines möglichen 2.0-Rollbacks. Vertrauen Sie mir, es ist mir ein paar Mal passiert, also bin ich sicher, dass es anderen passiert ist.

Ich stimme auch zu, dass Abstraktion die beste ist. Zusammen mit der Tatsache besteht der ursprüngliche Zweck eines ORM darin, RDBMS gut an die OO-Konzepte anzupassen. Wenn jedoch vor LINQ alles gut funktioniert hat, indem ein wenig von den OO-Konzepten abgewichen werden muss, dann schrauben Sie sie. Konzepte und Realität passen nicht immer gut zusammen. In der IT ist kein Platz für militante Eiferer.

Ich nehme an, Sie meinen Linq To Sql

Für jeden CRUD-Befehl ist es einfach, die Leistung einer gespeicherten Prozedur im Vergleich zu einer beliebigen Technologie zu profilieren. In diesem Fall ist jeder Unterschied zwischen den beiden vernachlässigbar. Versuchen Sie, ein Profil für ein 5-Feldobjekt (einfache Typen) mit mehr als 100.000 ausgewählten Abfragen zu erstellen, um herauszufinden, ob es einen echten Unterschied gibt.

Auf der anderen Seite wird der eigentliche Deal-Breaker die Frage sein, ob Sie sich wohl fühlen, wenn Sie Ihre Geschäftslogik in Ihre Datenbank aufnehmen oder nicht, was ein Argument gegen gespeicherte Prozeduren ist.

Laut Gurus definiere ich LINQ als Motorrad und SP als Auto. Wenn Sie eine kurze Reise unternehmen möchten und nur kleine Passagiere haben (in diesem Fall 2), wählen Sie LINQ. Aber wenn du eine Reise machen und eine große Band haben willst, solltest du SP wählen.

Die Wahl zwischen Motorrad oder Auto hängt von Ihrer Route (Geschäft), Länge (Zeit) und Passagieren (Daten) ab.

Hoffe es hilft, ich kann mich irren. : D.

Alle diese Antworten, die sich an LINQ orientieren, sprechen hauptsächlich von EINFACHER ENTWICKLUNG, die mehr oder weniger mit einer schlechten Qualität der Codierung oder Faulheit bei der Codierung zusammenhängt. Ich bin nur so.

Einige Vorteile oder Linq, die ich hier als einfach zu testen, leicht zu debuggen usw. gelesen habe, aber diese sind nicht mit der endgültigen Ausgabe oder dem Endbenutzer verbunden. Dies führt immer zu Leistungsproblemen des Endbenutzers. Was bringt es, viele Dinge in den Speicher zu laden und dann Filter bei der Verwendung von LINQ anzuwenden?

Auch hier ist TypeSafety darauf hingewiesen, dass "wir darauf achten, falsche Typumwandlungen zu vermeiden", was wiederum eine schlechte Qualität ist, die wir durch die Verwendung von linq verbessern möchten. Selbst in diesem Fall muss linq neu kompiliert werden, wenn sich irgendetwas in der Datenbank ändert, z. B. die Größe der String-Spalte, und wäre ohne das nicht typsicher. Ich habe es versucht.

Obwohl wir festgestellt haben, dass es bei der Arbeit mit LINQ gut, süß, interessant usw. ist, hat es den Scher-Nachteil, Entwickler faul zu machen :) und es wurde 1000-mal bewiesen, dass es im Vergleich zu Stored Procs schlecht (möglicherweise am schlechtesten) in Bezug auf die Leistung ist.

Sei nicht so faul. Ich bemühe mich sehr. :) :)

Für einfache CRUD-Operationen mit einem einzigen Datenzugriffspunkt würde ich LINQ wählen, wenn Sie mit der Syntax vertraut sind. Für eine kompliziertere Logik denke ich, dass Sprocs in Bezug auf die Leistung effizienter sind, wenn Sie gut mit T-SQL und seinen fortgeschritteneren Operationen umgehen können. Sie haben auch die Hilfe von Tuning Advisor, SQL Server Profiler, Debuggen Ihrer Abfragen von SSMS usw.

Die gespeicherte Prozedur erleichtert das Testen und Sie können die Abfrage ändern, ohne den Anwendungscode zu berühren. Auch bei linq bedeutet das Abrufen von Daten nicht, dass es die richtigen Daten sind. Um die Richtigkeit der Daten zu testen, muss die Anwendung ausgeführt werden. Mit gespeicherten Prozeduren ist es jedoch einfach zu testen, ohne die Anwendung zu berühren.

Das Ergebnis kann wie folgt zusammengefasst werden

LinqToSql für kleine Websites und Prototypen. Das spart wirklich Zeit für das Prototyping.

Sps: Universal. Ich kann meine Abfragen optimieren und immer ActualExecutionPlan / EstimatedExecutionPlan überprüfen.

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

Sowohl LINQ als auch SQL haben ihre Plätze. Beide haben ihre Nachteile und Vorteile.

Manchmal benötigen Sie für den komplexen Datenabruf gespeicherte Prozesse. Und manchmal möchten Sie vielleicht, dass andere Personen Ihren gespeicherten Prozess in SQL Server Management Studio verwenden.

Linq to Entities eignet sich hervorragend für die schnelle CRUD-Entwicklung.

Sicher können Sie eine App nur mit der einen oder anderen erstellen. Oder Sie können es verwechseln. Alles hängt von Ihren Anforderungen ab. Aber gespeicherte SQL-Prozesse werden nicht so schnell verschwinden.