Wechsel zu LINQ

Question

Ich denke darüber nach, Zeit mit dem Lernen und Verwenden von LINQ to SQL zu verbringen, aber nach jahrelangen Best Practices, die NICHT SQL einbetten, fällt es mir schwer, Paradigmen zu ändern.

Warum scheint es jetzt akzeptiert zu werden, Abfragen in kompilierten Code einzubetten? Es scheint in gewisser Weise für mich fast ein Rückschritt zu sein.

Hat jemand nach dem Wechsel zu LINQ Probleme mit dem Abfrage/Abfrage/Compile/Deploy-Zyklus gehabt?

Ich denke, ich könnte immer noch auf das fertige Entity Framework warten.

Was denkst du?

Answer 1

Der Vorteil von Linq zu Sql ist, dass es Abfragen in kompiliertem Code nicht wirklich einbettet - nicht wirklich. Die Linq-Anweisung bedeutet, dass Ihr .Net-Code tatsächlich über die erforderliche Logik verfügt, um die eingebettete Sql-Anweisung zu erstellen, nicht die Raw-Sql.

Es macht wirklich sehr viel Sinn, .Net-Code, der direkt in die Sql konvertiert, auszuführen, anstatt eine lange Liste von Sprocs mit zugehöriger Dokumentation. Der Linq-Weg ist viel einfacher zu pflegen und zu verbessern.

Ich glaube nicht, dass ich ein vorhandenes Projekt zu Linq wechseln würde - es ist wirklich ein Ersatz für die gesamte Datenebene und es kann die Art und Weise ändern, wie der gesamte Zugriff auf diese Ebene erfolgt. Wenn Sie nicht von einem sehr ähnlichen Modell wechseln, werden die Kosten für potenzielle Gewinne viel zu hoch sein.

Linq to wirkliche Macht der Sql in neue Anwendungen schnell schafft - es erlaubt Ihnen sehr schnell die Daten-Layer-Code zu erstellen.

Answer 2

Sie müssen LINQ to SQL als eine Abstraktion über das Schreiben von SQL direkt selbst denken. Wenn Sie sich damit abfinden können, haben Sie einen Schritt in die richtige Richtung gemacht. Sie müssen auch einige lang gehegte Überzeugungen loslassen, wie kompilierte Sprocs sind immer schneller und SQL-Konten sollten keine Lese-/Schreibberechtigungen haben.

Ich habe festgestellt, dass es möglich ist, schrittweise vorhandene Lösungen zu LINQ to SQL zu verschieben, solange eine klare DAL vorhanden ist und Sie nur die Implementierung ändern, ohne den Vertrag mit dem Code zu beeinträchtigen. Referenzlisten sind ein einfacher Kandidat, da sie nur wenig aussagekräftige, schreibgeschützte Datensätze sind. Die Hauptsache, die Sie beachten müssen, wenn die Nachrüstung mögliche mehrdeutige Klassennamen sind, ist, wenn Sie sie bereits manuell codiert haben, um die Datenbank zu modellieren.

Mit dem Rückblick auf LINQ zu SQL in ein großes Unternehmen (seit CTP Tage), würde ich es wieder in einem Herzschlag tun. Es ist nicht perfekt und es gibt Probleme, aber es gibt enorme Vorteile, insbesondere wenn es um Entwicklungsgeschwindigkeit und Wartbarkeit geht. Es ist ein neues Paradigma und definitiv ein Schritt vorwärts.

Answer 3

ich Ihren Punkt undertand, scheint dies in der Tat ein bisschen wie ein Schritt zurück ...

Eigentlich würde ich wahrscheinlich lenken von LINQ to SQL weg und schauen mehr auf LINQ to Entities, Ihre Entitäten modellieren Ihre konzeptionellen Datenmodell und ich persönlich fühlen sich wohler bei der Einbettung von Abfragen gegen ein konzeptionelles Modell in meinem Code. Das tatsächliche physische Modell wird durch ein Entitätsframework von Ihnen abstrahiert.

Dieser Link (entschuldigen Sie das Wortspiel) diskutiert LINQ to Entities und Entity Framework: http://msdn.microsoft.com/en-us/library/bb386992.aspx

ist dies ein interessanter Artikel die Vor- und Nachteile beider Ansätze discussign: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm

bearbeiten Ein anderer Gedanke, Wenn Sie nicht auf EF warten wollen, schauen Sie sich NHibernate an, Sie können LINQ auch dazu ... Siehe http://www.hookedonlinq.com/LINQToNHibernate.ashx

Answer 4

Es gibt eine Implementierung von LINQ to SQL nicht nur für SQL Server-Datenbanken, SQL Server-Entwicklung Bediener können auch die Vorteile dieses effizienten ORM nutzen. Wir haben bereits Support für LaodWith() auf Abfrageebene hinzugefügt und die Fehlerverarbeitung erweitert. Wir planen auch, alle drei Vererbungsmodelle (TPH, TPT, TPC) und Schlüsselfeldgenerierung zu unterstützen. Sie können die Liste der unterstützten Datenbanken finden here

Answer 5

Ich glaube nicht, es als SQL in Ihrem Code einbetten mehr als eine gespeicherte Proc Name Einbettung in Ihrem Code ist. In den meisten Fällen bedeutet eine Änderung an Ihrem Proc eine Änderung Ihres Codes. Zum Beispiel müssen Sie normalerweise einen neuen In/Out-Parameter hinzufügen oder eine Getter/Setter-Methode aktualisieren, um auf eine neue Spalte zu verweisen.

Was es tut, ist eine Menge von der Beinarbeit des Schreibens doppelt so viel Code entfernen, um Eigenschaften und Methoden in Ihrem Code mit Procs und Spalten in Ihrem DB auszurichten.