NHibernate vs. LINQ to SQL

StackOverflow https://stackoverflow.com/questions/26971

Frage

Als jemand, der noch keine der beiden Technologien in realen Projekten verwendet hat, frage ich mich, ob jemand weiß, wie sich diese beiden ergänzen und inwieweit sich ihre Funktionalitäten überschneiden?

War es hilfreich?

Lösung

LINQ to SQL zwingt Sie zur Verwendung des Tabellen-pro-Klasse-Musters.Die Vorteile dieses Musters bestehen darin, dass es schnell und einfach zu implementieren ist und nur sehr wenig Aufwand erforderlich ist, um Ihre Domain basierend auf einer vorhandenen Datenbankstruktur zum Laufen zu bringen.Für einfache Anwendungen ist dies vollkommen akzeptabel (und oft sogar vorzuziehen), aber für komplexere Anwendungen schlagen Entwickler oft die Verwendung von a vor Domänengesteuertes Design stattdessen ein Muster (was NHibernate ermöglicht).

Das Problem mit dem Tabelle-pro-Klasse-Muster besteht darin, dass Ihre Datenbankstruktur einen direkten Einfluss auf Ihr Domänendesign hat.Angenommen, Sie haben eine Kundentabelle mit den folgenden Spalten, um die primären Adressinformationen eines Kunden zu speichern:

  • Straßenadresse
  • Stadt
  • Zustand
  • Reißverschluss

Nehmen wir nun an, Sie möchten auch Spalten für die Postanschrift des Kunden hinzufügen, also fügen Sie der Tabelle „Kunden“ die folgenden Spalten hinzu:

  • MailingStreetAddress
  • MailingCity
  • MailingState
  • MailingZip

Mit LINQ to SQL verfügt das Customer-Objekt in Ihrer Domäne nun über Eigenschaften für jede dieser acht Spalten.Wenn Sie jedoch einem domänengesteuerten Entwurfsmuster folgen würden, hätten Sie wahrscheinlich eine Adressenklasse erstellt und Ihre Kundenklasse hätte zwei Adresseneigenschaften enthalten, eine für die Postanschrift und eine für die aktuelle Adresse.

Das ist ein einfaches Beispiel, aber es zeigt, wie das Muster „Tabelle pro Klasse“ zu einer etwas stinkenden Domäne führen kann.Am Ende liegt es an Ihnen.Auch hier ist LINQ to SQL aufgrund seiner Einfachheit ideal für einfache Apps, die nur grundlegende CRUD-Funktionen (Erstellen, Lesen, Aktualisieren, Löschen) benötigen.Aber ich persönlich verwende NHibernate gerne, weil es eine sauberere Domain ermöglicht.

Bearbeiten:@lomaxx – Ja, das Beispiel, das ich verwendet habe, war simpel und hätte optimiert werden können, um gut mit LINQ to SQL zu funktionieren.Ich wollte es so einfach wie möglich halten, um den Punkt klar zu machen.Der Punkt bleibt jedoch bestehen, dass es mehrere Szenarien gibt, in denen es eine schlechte Idee wäre, die Datenbankstruktur über die Domänenstruktur bestimmen zu lassen oder zumindest zu einem suboptimalen OO-Design zu führen.

Andere Tipps

Zwei Punkte, die bisher übersehen wurden:

  • LINQ to SQL funktioniert nicht mit Oracle oder eine andere Datenbank als SqlServer. Allerdings bieten Drittanbieter besseren Support für Oracle an, z.B. dotConnect von devArt, DbLinq, LightSpeed ​​von Mindscape Und ALinq.(Ich habe keine persönlichen Erfahrungen damit)

  • Linq zu NHibernate können Sie Linq mit einem Nhiberate, so kann es Entfernen Sie einen Grund, den Sie nicht verwenden möchten.

Auch das Neue fließende Schnittstelle zu Nhibernate scheint die Konfiguration der Nhibernate-Zuordnung weniger schmerzhaft zu machen.(Beseitigung eines der Schmerzpunkte von Nhibernate)

Aktualisieren

Linq to Nhiberate ist in Nhiberate v3, das jetzt verfügbar ist, besser Alpha.Es sieht so aus, als ob Nhiberate v3 gegen Ende dieses Jahres ausgeliefert werden könnte.

Der Entity-Framework Ab .net 4 sieht es auch nach einer echten Option aus.

@Kevin:Ich denke, das Problem mit dem Beispiel, das Sie präsentieren, besteht darin, dass Sie ein schlechtes Datenbankdesign verwenden.Ich hätte gedacht, Sie würden eine Kundentabelle und eine Adresstabelle erstellen und die Tabellen normalisieren.Wenn Sie dies tun, können Sie auf jeden Fall Linq To SQL für das von Ihnen vorgeschlagene Szenario verwenden.Scott Guthrie hat einen Tolle Beitragsreihe zur Verwendung von Linq To SQL Ich würde Ihnen dringend empfehlen, es sich anzusehen.

Ich glaube nicht, dass man sagen kann, dass Linq und NHibernate einander ergänzen, denn das würde bedeuten, dass sie zusammen verwendet werden könnten, und obwohl dies möglich ist, ist es viel besser, sich für eines zu entscheiden und dabei zu bleiben.

Mit NHibernate können Sie Ihre Datenbanktabellen auf äußerst flexible Weise Ihren Domänenobjekten zuordnen.Außerdem können Sie HBL zum Abfragen der Datenbank verwenden.

Mit Linq to SQL können Sie auch Ihre Domänenobjekte der Datenbank zuordnen, verwenden jedoch die Linq-Abfragesyntax zum Abfragen der Datenbank

Der Hauptunterschied besteht darin, dass die Linq-Abfragesyntax lautet Wird zur Kompilierungszeit vom Compiler überprüft, um sicherzustellen, dass Ihre Abfragen gültig sind.

Bei Linq ist zu beachten, dass es nur in .net 3.x verfügbar ist und nur in VS2008 unterstützt wird.NHibernate ist in 2.0 und 3.x sowie VS2005 verfügbar.

Beachten Sie bei NHibernate, dass weder Ihre Domänenobjekte noch die Zuordnungsdateien generiert werden.Sie müssen dies manuell tun.Linq kann
erledigen dies automatisch für Sie.

Fluent NHibernate kann Ihre Zuordnungsdateien basierend auf einfachen Konventionen generieren.Kein XML-Schreiben und stark typisiert.

Ich habe kürzlich an einem Projekt gearbeitet, bei dem wir aus Leistungsgründen von Linq To SQL zu NHibernate wechseln mussten.Insbesondere die Art und Weise, wie L2S die Objekte materialisiert, scheint langsamer zu sein als die von NHibernate, und auch das Änderungsmanagement ist recht langsam.Und es kann schwierig sein, das Änderungsmanagement für bestimmte Szenarien auszuschalten, in denen es nicht benötigt wird.

Wenn Sie Ihre Entitäten getrennt vom DataContext verwenden möchten – zum Beispiel in WCF-Szenarien – kann es sein, dass Sie große Probleme haben, sie erneut mit dem DataContext zu verbinden, um die Änderungen zu aktualisieren.Mit NHibernate hatte ich damit keine Probleme.

Was ich an L2S vermissen werde, ist vor allem die Codegenerierung, die die Beziehungen an beiden Enden der Entitäten auf dem neuesten Stand hält.Aber ich denke, es gibt auch einige Tools für NHibernate, um das zu tun ...

Können Sie klarstellen, was Sie mit „LINQ“ meinen?

LINQ ist keine Datenzugriffstechnologie, sondern lediglich eine Sprachfunktion, die Abfragen als natives Konstrukt unterstützt.Es kann jedes Objektmodell abfragen, das bestimmte Schnittstellen unterstützt (z. B.IQueryable).

Viele Leute bezeichnen LINQ To SQL als LINQ, aber das ist überhaupt nicht korrekt.Microsoft hat gerade LINQ To Entities mit .NET 3.5 SP1 veröffentlicht.Darüber hinaus verfügt NHibernate über eine LINQ-Schnittstelle, sodass Sie LINQ und NHibernate verwenden können, um auf Ihre Daten zuzugreifen.

Ich gehe davon aus, dass Sie mit LINQ LINQ to SQL meinen, da mit LINQ selbst keine Datenbankaktivitäten verknüpft sind.Es handelt sich lediglich um eine Abfragesprache, die jede Menge Syntax-Zucker enthält, damit sie wie SQL aussieht.

In den einfachsten Beispielen scheinen NHibernate und LINQ to SQL beide das gleiche Problem zu lösen.Sobald Sie das verstanden haben, werden Sie schnell feststellen, dass NHibernate viele Funktionen unterstützt, mit denen Sie wirklich umfangreiche Domänenmodelle erstellen können.Es gibt auch ein LINQ to NHibernate-Projekt, mit dem Sie LINQ verwenden können, um NHibernate auf die gleiche Weise abzufragen, wie Sie es mit LINQ to SQL tun würden.

Lassen Sie uns zunächst zwei verschiedene Dinge trennen:Bei der Datenbankmodellierung geht es um die Daten, bei der Objektmodellierung um Entitäten und Beziehungen.

Der Vorteil von Linq-to-SQL besteht darin, dass Klassen schnell aus dem Datenbankschema generiert werden können, sodass sie als aktive Datensatzobjekte verwendet werden können (siehe Definition des Entwurfsmusters für aktive Datensätze).

Der Vorteil von NHibernate besteht darin, dass es Flexibilität zwischen Ihrer Objektmodellierung und der Datenbankmodellierung ermöglicht.Die Datenbank kann so modelliert werden, dass sie Ihre Daten optimal widerspiegelt, beispielsweise unter Berücksichtigung der Leistung.Während Ihre Objektmodellierung die Elemente der Geschäftsregel am besten widerspiegelt, wenn Sie einen Ansatz wie Domain-Driven-Design verwenden.(siehe Kommentar von Kevin Pang)

Bei älteren Datenbanken mit schlechten Modellierungs- und/oder Namenskonventionen spiegelt Linq-to-SQL diese unerwünschten Strukturen und Namen in Ihren Klassen wider.Allerdings kann NHibernate dieses Durcheinander mit Datenmappern verbergen.

Bei Greenfield-Projekten, bei denen Datenbanken über eine gute Benennung und geringe Komplexität verfügen, kann Linq-to-SQL eine gute Wahl sein.

Sie können es jedoch verwenden Fließendes NHibernate mit automatischen Zuordnungen für den gleichen Zweck mit Mapping als Konvention.In diesem Fall müssen Sie sich keine Gedanken über Datenzuordnungen mit XML oder C# machen und lassen NHibernate das Datenbankschema aus Ihren Entitäten basierend auf einer Konvention generieren, die Sie anpassen können.

Andererseits ist die Lernkurve von Linq-to-SQL kleiner als die von NHibernate.

Oder Sie könnten das Castle ActiveRecords-Projekt verwenden.Ich verwende das seit kurzer Zeit, um neuen Code für ein Legacy-Projekt zu erstellen.Es verwendet NHibernate und arbeitet mit dem aktiven Datensatzmuster (was angesichts des Namens, den ich kenne, überraschend ist).Ich habe es noch nicht versucht, aber ich gehe davon aus, dass es für einen Teil oder das gesamte Projekt nicht allzu viel wäre, wenn Sie nach der Nutzung das Bedürfnis verspüren, sich direkt an den NHibernate-Support zu wenden.

Wie Sie geschrieben haben "für eine Person, die keines von beiden verwendet hat" LINQ to SQL ist einfach zu bedienen, sodass jeder es problemlos verwenden kann Es unterstützt auch Verfahren, was in den meisten Fällen hilft.Angenommen, Sie möchten Daten aus mehr als einer Tabelle abrufen, dann schreiben Sie eine Prozedur und ziehen Sie diese Prozedur in den Designer, und es wird alles für Sie erstellt. Angenommen, Ihr Prozedurname ist "CUSTOMER_ORDER_LINEITEM", die Datensätze aus allen drei Tabellen abrufen, dann schreiben Sie einfach

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

Sie können Ihr Records-Objekt auch in der foreach-Schleife verwenden, was von NHibernate nicht unterstützt wird

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top