DevArt 的 dotConnect for Oracle 与 DataDirect 的 ADO.NET 数据提供程序
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/1781679/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
DevArt's dotConnect for Oracle vs DataDirect's ADO.NET data provider
提问by Chai
Has anybody done a comparative analysis of dotConnect for Oracle from DevArt and the ADO.NET data provider from DataDirect.
有没有人对 DevArt 的 dotConnect for Oracle 和DataDirect的ADO.NET 数据提供程序进行过比较分析。
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:
我们正在考虑将这些框架中可用的实体框架支持用于关键企业应用程序。我读过的一些文章建议如下:
- DevArt dotConnect is much faster as compared to DataDirect
- DataDirect license is more expensive that the DevArt license
- 与 DataDirect 相比,DevArt dotConnect 快得多
- DataDirect 许可证比 DevArt 许可证更贵
Can anybody throw more light on the technical aspects so as to aid the decision making process?
任何人都可以更多地了解技术方面以帮助决策过程吗?
回答by Devart
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.
由于没有来自无利害关系方的人尚未发表任何评论,我们将尽量发表中立的评论。
Devart 拥有更长的 EF 支持历史 - 自 2007 年 8 月 30 日起。在这两年中,我们考虑了大量错误报告和用户请求。我们还创建并发布了我们的产品Entity Developer- 一个强大的设计时工具。
我们不能称我们对 Oracle 的实体框架支持是理想的——这个 ORM 最初是为 MS SQL Server 设计的,因此考虑到其他 DBMS 的奇迹的可能性非常有限。仅提及 CROSS APPLY 和 OUTER APPLY问题就足够了。
但是,尽管存在这些问题,我们的大多数用户都能够成功且舒适地使用实体框架。
这足以说明问题,但您提到了“关键企业应用”。在这种情况下,我们建议您查看我们特定于 Oracle 的 LINQ to SQL 实现 - LINQ to Oracle。
LINQ to SQL 不会假装构建跨数据库解决方案,因此允许考虑单独 DBMS(尤其是 Oracle)的特性。与 Entity Framework 不同,我们只能部分控制生成的 SQL 查询,而在 LINQ to Oracle 案例中,我们可以完全控制流程。这一事实使我们有机会生成快速有效的 Oracle 特定查询,并加快错误修复和改进过程。
在遗留 Oracle 数据库的情况下,EF 通常难以应用,这与 LINQ to Oracle 不同。
使用 LINQ to Oracle 模型的设计时工作也是使用 Entity Developer 执行的。
回答by Sebastian Good
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.
这里是最新的反馈,但在我们现在正在加载数十万行的一些测试中,DataDirect 驱动程序是最快的——大约比 MSFT 驱动程序快 10 倍。DevArt 也非常快,但只有几秒钟,然后它所有的时间都花在垃圾收集上。在我们的案例中,原始选择速度的显着方面是驱动程序将它们的值转换为 .NET 对象的智能程度,不一定是它们从网络中提取字节的速度。