DevArt's dotConnect for Oracle vs DataDirect's ADO.NET data provider

Question

Has anybody done a comparative analysis of dotConnect for Oracle from DevArt and the ADO.NET data provider from DataDirect.

We are thinking of using the Entity Framework support available in these frameworks for a critical enterprise application. Some articles that I read suggest the following:

1. DevArt dotConnect is much faster as compared to DataDirect
2. DataDirect license is more expensive that the DevArt license

Can anybody throw more light on the technical aspects so as to aid the decision making process?

Nemhauser

Answer 1

As nobody from disinterested parties haven't left any comments yet, we'll try to post as neutral comment as possible.
Devart has longer EF support history - since Aug 30th, 2007. During these two years we have taken into account numerous bug reports and user requests. We also have created and ship with our products Entity Developer - a powerful design time tool.
We cannot call our Entity Framework support for Oracle an ideal one - this ORM was initially designed for MS SQL Server, so the possibility to take into account the marvels of other DBMSs is significantly limited. It is enough to mention only the CROSS APPLY and OUTER APPLY problem.
But, in spite of these problems, most of our users are capable of working with Entity Framework successfully and comfortably.
That will be sufficient to say, but you have mentioned "critical enterprise allpications". In this case we recommend you to take a look at our Oracle-specific LINQ to SQL implementation - LINQ to Oracle.
LINQ to SQL does not pretend to build cross-database solutions and hence allows to take into consideration peculiarities of a separate DBMS, Oracle in particular. Unlike Entity Framework, where we have only partial control over the generated SQL queries, in the LINQ to Oracle case we have full control over the process. This fact gives us an opportunity to generate fast and valid Oracle-specific queries and also speeds up bug fixing and improvement process.
In case of legacy Oracle databases EF usually is hard to apply, unlike LINQ to Oracle.
Design time work with LINQ to Oracle model is also performed using Entity Developer.

Beige

1. Can you throw more light on the statement "possibility to take into account the marvels of other DBMSs is significantly limited"? 2. Doesn't LINQ to Oracle lack the features like customizing the model mappings using features like inheritance, etc. – Nemhauser

1.There is no possibility to return several result sets from the stored procedure in EF. It is impossible to use sequences not associated with triggers in EF. And what about data types not from the "number, string, datetime, binary, guid" enumeration? And the list does not end on these problems. 2. LINQ to Oracle has support for the Table Per Hierarchy inheritance. We support all major features of LINQ to SQL. – Beige

Answer 2

Late-breaking feedback here, but in some testing we're doing right now loading hundreds of thousands of rows, the DataDirect driver is the fastest -- about 10 times faster than the MSFT driver. DevArt is pretty fast too, but only for a few seconds, then it spends all its time garbage collecting. The distinguishing aspect for raw select speed in our case is how smart the drivers are about converting their values into .NET objects, not necessarily how fast they can pull bytes off the wire.

Artair