2009-11-23 9 views
5

Hat jemand eine vergleichende Analyse von dotConnect for Oracle von DevArt und der ADO.NET data provider from DataDirect gemacht.DevArt's dotConnect für Oracle vs DataDirect's ADO.NET Datenprovider

Wir denken über die Unterstützung von Entity Framework in diesen Frameworks für eine kritische Unternehmensanwendung nach. Einige Artikel, die ich vorschlagen, lesen Sie die folgenden:

  1. DevArt dotConnect ist viel schneller im Vergleich zu Datadirect
  2. Datadirect-Lizenz ist teurer, dass die DevArt Lizenz

Kann jemand mehr Licht auf das werfen technische Aspekte, um den Entscheidungsprozess zu unterstützen?

Antwort

5

Da niemand aus uneigennützigen Parteien noch keine Kommentare hinterlassen hat, werden wir versuchen, so neutral wie möglich zu schreiben.
Devart hat eine längere EF-Support-Historie - seit dem 30. August 2007. In diesen zwei Jahren haben wir zahlreiche Fehlerberichte und Benutzeranfragen berücksichtigt. Wir haben auch erstellt und liefern mit unseren Produkten Entity Developer - ein leistungsstarkes Design-Zeit-Tool.
Wir können unseren Entity Framework-Support für Oracle nicht als ideal bezeichnen - dieser ORM wurde ursprünglich für MS SQL Server entwickelt, so dass die Möglichkeit, die Wunder anderer DBMS zu berücksichtigen, erheblich eingeschränkt ist. Es ist genug, nur die Cross Apply und Outer Apply problem zu erwähnen.
Aber trotz dieser Probleme sind die meisten unserer Benutzer in der Lage, mit Entity Framework erfolgreich und komfortabel zu arbeiten.
Das wird ausreichen, um zu sagen, aber Sie haben "kritische Unternehmenspicpications" erwähnt. In diesem Fall empfehlen wir Ihnen einen Blick auf unsere Oracle-spezifische LINQ to SQL-Implementierung - LINQ to Oracle.
LINQ to SQL gibt nicht vor, datenbankübergreifende Lösungen zu erstellen, und berücksichtigt daher Besonderheiten eines separaten DBMS, insbesondere Oracle. Im Gegensatz zu Entity Framework, wo wir nur eine begrenzte Kontrolle über die generierten SQL-Abfragen haben, haben wir im Fall LINQ to Oracle die volle Kontrolle über den Prozess. Diese Tatsache gibt uns die Möglichkeit, schnelle und gültige Oracle-spezifische Abfragen zu generieren und beschleunigt die Problembehebung und Verbesserung.
Bei älteren Oracle-Datenbanken ist EF im Gegensatz zu LINQ to Oracle normalerweise schwer anzuwenden.
Entwurfszeitarbeit mit LINQ to Oracle-Modell wird auch mithilfe von Entity Developer durchgeführt.

+0

1. Können Sie mehr Licht auf die Aussage "die Möglichkeit, die Wunder der anderen DBMS zu berücksichtigen ist deutlich begrenzt" werfen? 2. LINQ to Oracle fehlt die Funktionen wie Anpassen der Modellzuordnungen mit Funktionen wie Vererbung, etc. – Chai

+1

1. Es gibt keine Möglichkeit, mehrere Ergebnismengen aus der gespeicherten Prozedur in EF zurückzugeben. Es ist nicht möglich, Sequenzen zu verwenden, die nicht mit Triggern in EF verknüpft sind. Und was ist mit Datentypen nicht von der "number, string, datetime, binary, guid" Aufzählung? Und die Liste endet nicht mit diesen Problemen. 2. LINQ to Oracle unterstützt die Vererbung der Tabelle pro Hierarchie.Wir unterstützen alle wichtigen Funktionen von LINQ to SQL. – Devart

3

Late-breaking-Feedback hier, aber in einigen Tests, die wir jetzt gerade hunderttausende Zeilen laden, ist der DataDirect-Treiber der schnellste - etwa 10 mal schneller als der MSFT-Treiber. DevArt ist auch ziemlich schnell, aber nur für ein paar Sekunden, dann verbringt es seine ganze Zeit damit, Müll zu sammeln. Der entscheidende Aspekt für die rohe Select-Geschwindigkeit in unserem Fall ist, wie intelligent die Treiber ihre Werte in .NET-Objekte konvertieren, nicht unbedingt, wie schnell sie Bytes aus der Leitung ziehen können.

Verwandte Themen