Soll ich LINQ To SQL verwenden?

8

Zur Zeit verwende ich NetTiers, um meine Datenzugriffsschicht und Serviceschicht zu generieren. Ich benutze NetTiers seit über 2 Jahren und finde es sehr nützlich. Irgendwann muss ich LINQ anschauen, also sind meine Fragen ...

  1. Hat jemand anderes von NetTiers zu LINQ To SQL gewechselt?
  2. War das eine gute oder schlechte Sache?
  3. Gibt es etwas, auf das ich achten sollte?
  4. Würden Sie diesen Schalter empfehlen?

Grundsätzlich würde ich alle Gedanken begrüßen .

    
Rippo 17.09.2008, 09:13
quelle

6 Antworten

5
  1. Nein
  2. Siehe # 1
  3. Sie sollten sich vor dem Aufwand für die Standardabstraktion hüten. Es ist auch sehr SQL Server in seinem aktuellen Zustand basiert.
  4. Verwenden Sie SQL Server, dann vielleicht. Wenn Sie LINQ jetzt für andere Dinge wie XML-Daten (groß), Objektdaten, Datasets verwenden, dann sollten Sie für alle eine einheitliche Datensyntax verwenden. Wie Lagerdalek erwähnt, wenn es nicht kaputt ist, nicht tun repariere es. Aus dem schnellen Blick auf. Nettiers Application Framework, würde ich sagen, wenn Sie bereits eine Investition mit dieser Lösung haben, scheint es Ihnen viel mehr als eine einfache Datenzugriffsschicht zu geben und Sie sollten dabei bleiben.

Aus meiner Erfahrung heraus ist LINQ to SQL eine gute Lösung für kleine bis mittlere Projekte. Es ist ein ORM, das eine großartige Möglichkeit ist, die Produktivität zu steigern. Es sollte auch sollte Ihnen eine weitere Abstraktionsebene geben, mit der Sie die darunter liegende Ebene für etwas anderes ändern können. Der Designer in Visual Studio (und ich glaube VS Express auch) ist sehr einfach und einfach zu bedienen. Sie erhalten eine gemeinsame Drag-Drop- und eigenschaftsbasierte Bearbeitung der Objektzuordnungen.

@ Jason Jackson - Der Designer lässt Sie Fügen Sie Eigenschaften per Hand hinzu. Sie müssen jedoch die Attribute für diese Eigenschaft angeben. Wenn Sie dies einmal tun, dauert es möglicherweise 3 Minuten länger als beim ersten Ziehen der Tabelle in den Designer. Sie ist jedoch nur einmal pro Änderung in der Datenbank erforderlich selbst. Dies unterscheidet sich nicht wesentlich von anderen ORMs, aber Sie haben Recht, dass sie das viel einfacher machen und nur die Eigenschaften finden, die sich geändert haben, oder sogar ein Refactoring-Tool für solche Bedürfnisse implementieren.

Ressourcen:

Beachten Sie, dass Parallel LINQ entwickelt wird, um eine wesentlich höhere Leistung bei Multicore zu ermöglichen Maschinen.

    
Steve Tranby 08.10.2008, 22:12
quelle
2

Ich habe versucht, Linq für SQL in einem kleinen Projekt zu verwenden, weil ich dachte, dass ich etwas wollte, das ich schnell generieren konnte. Ich habe im Designer viele Probleme bekommen. Wenn Sie beispielsweise einer Tabelle eine Spalte hinzufügen müssen, müssen Sie die Tabellendefinition im Designer grundsätzlich entfernen und neu hinzufügen. Wenn Sie Eigenschaften für die Tabelle festgelegt haben, müssen Sie diese Eigenschaften erneut festlegen. Das hat den Entwicklungsprozess für mich wirklich gebremst.

LINQ to SQL selbst ist nett. Ich mag die Erweiterbarkeit sehr. Wenn sie den Designer verbessern können, könnte ich es erneut versuchen. Ich denke, dass das Framework von etwas mehr Funktionalität profitieren würde, die auf ein unzusammenhängendes Modell wie Web-Entwicklung abzielt.

Sehen Sie sich Scott Guthries LINQ to SQL an Reihe von Blog-Posts für einige großartige Beispiele, wie man es benutzt.

    
Jason Jackson 30.09.2008 19:18
quelle
1

NetTiers eignet sich sehr gut, um eine schwere und robuste DAL zu erzeugen, und wir verwenden sie intern für Kernbibliotheken und Frameworks.

Wie ich es sehe, ist LINQ (in allen seinen Inkarnationen, aber speziell, wie ich denke, dass Sie nach SQL fragen) fantastisch für schnellen Datenzugriff, und wir verwenden es im Allgemeinen für flexiblere Fälle.

Beide Technologien sind ziemlich unflexibel zu ändern, ohne die Code- oder dbml-Ebene zu regenerieren.

Wenn man das sagt, ist LINQ 2 SQL eine ziemlich robuste Lösung, und Sie könnten es sogar für die zukünftige Entwicklung verwenden, weil es einfach zu benutzen ist, aber ich würde Ihre aktuelle DAL dafür nicht wegwerfen - wenn sie es ist Aint brach ...

    
johnc 17.09.2008 09:20
quelle
0

Meine Erfahrung sagt mir, dass die Verwendung von linq die Dinge schneller erledigt, die eigentlichen Aktionen in der Datenbank jedoch langsamer sind.

Also ... wenn Sie eine kleine Datenbank haben, werde ich sagen, gehen Sie dafür. Wenn nicht, würde ich auf einige Verbesserungen warten, bevor ich

ändere     
Sérgio 17.09.2008 09:42
quelle
0

Ich benutze LINQ to SQL auf einem ziemlich großen Projekt (ungefähr 150 Tabellen) und es funktioniert sehr gut für mich. Das letzte ORM, das ich benutzt habe, war IBatis und es funktionierte gut, aber ich brauchte eine Menge Beinarbeit, um deine Mappings zu erledigen. LINQ to SQL funktioniert sehr gut für mich und hat sich bisher als sehr einfach in der Anwendung erwiesen. Es gibt definitiv einige Unterschiede, die Sie im Übergang überwinden müssen, aber ich würde es empfehlen.

Seitliche Anmerkung, ich habe NetTiers noch nie benutzt oder gelesen, daher werde ich seine Effektivität nicht abzählen, aber LINQ to SQL hat sich im Allgemeinen als extrem brauchbares ORM erwiesen.

    
Quintin Robinson 30.09.2008 19:25
quelle
0

Unser Team verwendete NetTiers und fand es nützlich. ABER ... je mehr wir es benutzten, desto mehr Kopfschmerzen und Schmerzpunkte fanden wir. Zum Beispiel müssen Sie, wann immer Sie Änderungen an der Datenbank vornehmen, die DAL mit CodeSmith neu generieren, was Folgendes beinhaltet:

  • Generieren von Tausenden von Codezeilen in 3 separaten Projekten
  • Hunderte von gespeicherten Prozeduren werden neu generiert

Vielleicht gibt es andere Möglichkeiten, das zu tun, aber das mussten wir tun. Das Re-Gen des Quellcodes war ok, unheimlich, aber ok. Das eigentliche Problem kam mit den gespeicherten Prozeduren. Es wurden keine nicht verwendeten gespeicherten Prozeduren bereinigt. Wenn Sie also eine Tabelle aus Ihrem Schema entfernt und Ihren DAL neu erstellt haben, wurden die gespeicherten Prozeduren für diese Tabelle nicht entfernt. Außerdem wurde dies für Datenbankänderungsskripte ziemlich problematisch, wo wir die alte Datenbankstruktur mit der neuen Datenbankstruktur vergleichen und ein Änderungsskript erstellen mussten, um Client-Installationen zu aktualisieren. Dieses Skript könnte in die Zehntausende von Zeilen SQL-Code laufen und wenn es ein Problem gab, das es ausführten, was dort immer war, war es ziemlich mühsam, es zu lösen.

Dann ging das Licht an, NHibernate als ORM. Es hat sicherlich eine Anlaufzeit, aber es ist es wert. Es gibt eine Menge Unterstützung dafür, wenn etwas getan werden muss, ist es mehr als wahrscheinlich, dass es vorher getan wurde. Es ist äußerst flexibel und erlaubt Ihnen, jeden Aspekt und dann einige davon zu kontrollieren. Es wird auch einfacher und einfacher zu bedienen. Fluent Nhibernate ist eine gute Möglichkeit, die benötigten XML-Mapping-Dateien loszuwerden, und NHibernate Profiler bietet eine hervorragende Schnittstelle, um zu sehen, was hinter den Kulissen passiert, um die Effizienz zu erhöhen und Redundanzen zu beseitigen.

Der Wechsel von NetTiers zu NHibernate war schmerzhaft, aber auf eine gute Art und Weise. Es hat uns gezwungen, in eine bessere Architektur zu gehen und funktionelle Bedürfnisse neu zu bewerten. NetTiers stellte Tonnen von Datenzugriffscode zur Verfügung, holte diese Entität durch ihre ID, holte diese andere Entität durch ihren Fremdschlüssel, erhielt eine Liste und eine Liste von diesem und jenem, aber das meiste war unnötig und ungenutzt. NHibernate mit einem generischen Repository und angepassten Repositories nur dort, wo es benötigt wird, hat Tonnen ungenutzten Codes reduziert und die Lesbarkeit und Zuverlässigkeit deutlich verbessert.

    
Chris Conway 28.04.2009 02:27
quelle

Tags und Links