Schnellste Weg, um abrufen von Daten aus einer Datenbank .NET?

Mit ADO.NET, was ist der Schnellste Weg, um Daten von der Datenbank abzurufen und füllen Sie die Daten in meine business-Objekte?

Welche soll ich verwenden? DBDataReader , DBDataAdapter oder andere Klassen?

Gibt es eine Möglichkeit um diesen Vorgang zu automatisieren? Sagen wir, basierend auf den Namen der Eigenschaft und deren Abgleich mit einer Datenbank-Feld-Namen?

InformationsquelleAutor aryaxt | 2011-09-25
  1. 8

    Das klingt genau wie das, was ein ORM oder micro-ORM hat. Hier ist die Ausgabe von dapper-dot-net's performance-tests (laufen, 1 minute vor, auf einem PC, der ist auch beschäftigt, einige transcoding, also nicht 100% zuverlässig ist - bitte führen Sie sich selbst)... Das ist auch eine sehr begrenzte test - wie immer, tests sollten repräsentativ für Ihre Umgebung - aber da können wir nicht Vorhersagen Ihrer Umgebung, nutzen wir unsere Umgebung statt! Ich ' ve markiert die "dapper", wie <==== dapper

    Running 500 iterations that load up a post entity
Mapper Query (non-buffered) took 57ms          <==== dapper
hand coded took 57ms
Dynamic Mapper Query (buffered) took 58ms      <==== dapper
PetaPoco (Fast) took 58ms
Dynamic Mapper Query (non-buffered) took 59ms  <==== dapper
Mapper Query (buffered) took 60ms              <==== dapper
Dapper.Cotrib took 60ms                        <==== dapper
PetaPoco (Normal) took 66ms
Dynamic Massive ORM Query took 67ms
BLToolkit took 88ms
Simple.Data took 96ms
Linq 2 SQL Compiled took 99ms
NHibernate Session.Get took 127ms
SubSonic Coding Horror took 128ms
Entity framework CompiledQuery took 130ms
NHibernate HQL took 132ms
NHibernate SQL took 134ms
NHibernate Criteria took 173ms
Soma took 184ms
Linq 2 SQL ExecuteQuery took 230ms
Linq 2 SQL took 694ms
NHibernate LINQ took 700ms
Entity framework ESQL took 730ms
Entity framework ExecuteStoreQuery took 735ms
Entity framework took 991ms
Entity framework No Tracking took 1011ms
SubSonic ActiveRecord.SingleOrDefault took 4345ms
(end of tests; press any key)
    • Haben Sie gehört der SqlFu? Gleich schnell, wenn nicht schneller nach einigen benchmarking: 1) in Ihre Hauptseite und 2) aus FluentData Diskussion Seite. Es wäre toll, wenn könnten Sie gehören SqlFu im dapper's original-test-suite.
    • Ich werde einen Blick nehmen. Re perf: es gibt nicht viel zu bemerken zwischen dapper und raw ado.net - aber ich nehme einen Blick!
    • Hahaha, das ist ein sehr guter Punkt, aber immer noch.. zur Beruhigung der religiöse Fanatiker wie mich! 😛 Trotzdem, SqlFu hat eine syntax sehr nah an dapper..
    • Als die SqlFu Autor, ich kann Ihnen sagen, dass dapper ist die Schnellste, ABER es hat die wenigsten features, die im Vergleich zu anderen micro-orms. Dapper ist für absolute Geschwindigkeit, die anderen sind für eine balance zwischen Geschwindigkeit und features.
    • Wo ist SqlDataReader im benchmark?
    • Sie alle verwenden SqlDataReader; allerdings, wenn du meinst, nur SqlDataReader, dann: "hand-coded"

    InformationsquelleAutor Marc Gravell
  2. 5

    Wenn Sie möchten, automatisierte Sie sind auf der Suche für ein orm. Sie vielleicht überprüfen Sie heraus einige der leichter wieght wie massive, ormlite, dapper und PetaPoco.

    InformationsquelleAutor Aaron Fischer
  3. 4

    Verwenden ADO.NET, was ist der Schnellste Weg, um Daten von der Datenbank abzurufen und füllen Sie die Daten in meine business-Objekte?

    Gibt es eine Möglichkeit um diesen Vorgang zu automatisieren? Sagen wir, basierend auf den Namen der Eigenschaft und deren Abgleich mit einer Datenbank-Feld-Namen?

    Dapper. Absolut rasend.

    • Hinzufügen, dass; in den dapper-test-suite, die wir bewusst ausführen, ein paar raw-perf-tests gegen alle Motoren, die wir kennen, und dapper gewinnt. Beachten Sie, dass einige andere sind in der Nähe; jedoch L2S und EF sind nirgendwo in der Nähe. Dapper ' s design ist alles über die Geschwindigkeit. Einige andere (einfache.Daten, zum Beispiel), die sich in Erster Linie an Entwickler Bequemlichkeit (aber immer noch viel schneller als EF usw.)
    • Nehmen Sie in Betracht, wenn diese orms tun das gleiche, wenn benchmarking? Zum Beispiel kann es sein, orms übernimmt den Verbindungsaufbau und schließen sich (da in realen Szenarien, die Sie nicht diese für viele Iterationen) und einer solchen in-Schleife wird sehr langsam im Vergleich zu anderen, die läuft auf einer Instanz öffnen. Ich denke Subsonic ActiveRecord in Ihrer suite öffnen und schließen ist die Verbindung jedes mal. So sollte FluentData dem Sie noch nicht gemessen sowieso.
    InformationsquelleAutor jason
Schreibe einen Kommentar