none
Linq to SQL vs Linq to Entity vs nHibernate

    Frage

  • Hallo Community,

    ich bin mir nicht ganz sicher ob dieser Thread hier reinpasst aber hier mein Problem:

    Welches der 3 folgenden Technologien ist DIE schnellste:

    1. Linq to SQL

    2. Linq to Entity

    3. nHibernate

    Ich bin auf der Suche nach wirklichen Performance Tests von einfachen Abfragen, bis zu enterprise applications.

    Leider konnte ich im Internet nur Aussagen finden ohne wirkliche Tests. Wenn man dann doch mal einen Test findet ist dieser 2-3 Jahre alt. Ich denke, dass sich gerade im Bereich Linq to Entity einiges getan hat, deswegen frage ich mich wie es derzeit bei der Performance aussieht.

    Bitte keine Vermutungen oder "gefühlte" Geschwindigkeiten in diesen Thread einfliesen lassen. 

     

    Vielen Dank im Voraus!

    Montag, 10. Oktober 2011 13:12

Antworten

  • Also Linq scheint unter manchen Umständen wohl wirklich gefühlt langsamer zu sein. nHibernate habe ich mir jetzt wirklich gut angeschaut und finde es für große Projekte besser. Für kleine greife ich doch lieber zu LINQ to SQL.
    Donnerstag, 27. Oktober 2011 12:51

Alle Antworten

  • Ich glaube ein solcher Vergleich ist extrem schwierig. Es geht ja a)
    nicht nur um den eigentliche OR-Mapper, sondern auch noch wie man ihn
    verwendet. Es nutzt nichts den schnellsten OR-Mapper zu haben, und
    diesen dann "falsch" zu verwenden.
     
    Außerdem kommt es ja noch auf deine Umgebung an: was für eine Datenbank
    verwendest du? Ist es eine Desktop, Silverlight, Web,
    JavaScript-basierte .... Anwendung? Gibt es mehr als einen Server (bei
    Web-Apps, oder bei Silverlight mehr als einen Server der Web-Services
    bereitstellt)? Was für Anforderungen wird an Caching gestellt? Gibt es
    die Datenbank schon oder wird sie neu erstellt? Wieviele Daten werden in
    welchem Zeitraum durch den OR-Mapper bearbeitet? Wie Umfangreich sind
    die Anwendungen? Wie modular (wiederverwendtbar) wird der Datenzugriff sein?
     
    Das sind nur die Fragen, die mir so spontan eingefallen sind. Zudem: es
    macht nicht immer für jede Aufgabe Sinn einen OR-Mapper zu verwenden. Um
    mal eben ein paar Daten in einer Datenbank zu aktualisieren ist es ggf.
    Sinnvoller direkt mit SQL-Befehlen zu arbeiten, anstatt mit OR-Mappern.
    Wenn es um die Implementierung von Geschäftslogik und
    wiederverwendtbaren Datenzugriffen geht, vielleicht noch in einem
    größeren Entwicklerkreis, dann macht ORM in meinen Augen Sinn.
     
    Ansonsten hat Ayende Rahien letztes Jahr mal einen Vergleich von
    NHibernate vs. EF 4.0
    erstellt. Aber wie du ja auch schon gesagt hast, tut sich bei den
    Frameworks ständig etwas.
     
    BTW: Wenn du nicht MSSQL-Server als Datenbank verwendest, dann ist
    LINQ-To-SQL ja schon raus, und wieviele EF Provider es aktuell gibt kann
    ich nicht genau sagen. Wenn du also was anderes als DB unterstützen
    willst/musst, dann bist du mit NHibernate auf jeden Fall am flexibelsten.
     
    --
     
    Henning Eiben
     
    busitec GmbH
    Consultant
     
     
    Rudolf-Diesel-Straße 59
    48157 Münster
    www.busitec.de
      
    Sitz der Gesellschaft: Münster
    HR B 55 75 - Amtsgericht Münster
    USt-IdNr. DE 204607833 - St.Nr. 336/5704/1277
    Geschäftsführer: Henning Eiben, Martin Saalmann, Simon Schwingel
     
     
    Donnerstag, 13. Oktober 2011 06:38
  • Vielen dank für deine ausführliche Antwort!

    Also um eine richtige Aussage zu machen wäre natürlich eine Layer die nur für die Daten zuständig wäre nötig um die Frage ob Silverlight, Desktop, Web auszuschlissen. Da würde ich auf REST setzen um ein einheitliches Ergebnis zu bekommen. Alles danach ist dann ein "Problem" der verwendeten Anzeige.

    Die Datenbank soll immer SQL Server sein.

    Im Grunde möchte ich einfach handfeste Aussagen über die Abfragegeschwindigkeit um nicht wie viele andere vorlieben mit "besserer" Technologie zu verwechseln.

    Ich denke das ich eigene Tests machen muss/werde.

     

     

    Freitag, 14. Oktober 2011 09:57
  • Tja, da hatte ich mal so einen Vergleich, aber ich fürchte der ist halt
    auch nicht mehr so ganz aktuell.
     
    Aber wie ich mit meinen vielen Fragen zeigen wollte, hängt die Wahl des
    ORM von sehr vielen Faktoren ab. Um also zu wissen welcher ORM objektiv
    wirklich die bessere Wahl für deine Anwendung ist müsstest du die
    schlussendlich mit jedem ORM einmal entwickeln. Annahme: du hast von
    jedem ORM den gleichen Know-How-Stand, so dass du die ORM jeweils gleich
    optimal einsetzt.
     
    Ansonsten sind die Ergebnisse einer Performance-Messung ja nur für die
    jeweiligen Testszenarien aussagekräftig. Wenn dein Anwendungsszenario
    abweicht, dann kommst du zu anderen Ergebnissen.
     
    Außerdem würde ich auch weiche Faktoren durchaus mit berücksichtigen:
    bei welcher Technik habe ich mehr Know-How? Wo kann ich micht schneller
    einarbeiten? Wo komme ich mehr Hilfe bei Problemen? Welches
    Technik/welches Know-How kann ich in Zukunft mit der höchsten
    Wahrscheinlichkeit weiter nutzen? Solche Faktor spielen in meinen Augen
    durchaus eine Rolle, auch wenn Sie nicht zur Geschwindigkeit deiner
    Anwendung beitragen, so helfen Sie doch bei der Geschwindigkeit der
    Umsetzung, bei der Zeit für Bugfixes/neue Releases etc.
     
    --
     
    Henning Eiben
     
    busitec GmbH
    Consultant
     
     
    Rudolf-Diesel-Straße 59
    48157 Münster
    www.busitec.de
      
    Sitz der Gesellschaft: Münster
    HR B 55 75 - Amtsgericht Münster
    USt-IdNr. DE 204607833 - St.Nr. 336/5704/1277
    Geschäftsführer: Henning Eiben, Martin Saalmann, Simon Schwingel
     
     
    Freitag, 14. Oktober 2011 17:17
  • Wenn du Daten updaten bzw. ändern möchtest (angenommen, du hast eine SQL-Datenbank) dann würde ich dir persönlich von LINQ to Entity abraten.

    Dafür ist LINQ to SQL einfacher zu handhaben.

    Freitag, 21. Oktober 2011 15:36
  • Also Linq scheint unter manchen Umständen wohl wirklich gefühlt langsamer zu sein. nHibernate habe ich mir jetzt wirklich gut angeschaut und finde es für große Projekte besser. Für kleine greife ich doch lieber zu LINQ to SQL.
    Donnerstag, 27. Oktober 2011 12:51