问DevArt的dotConnect for Oracle的ADO.NET数据提供程序

EN

由于没有人从无私的各方还没有留下任何评论，我们将尝试张贴尽可能中性的评论。

德瓦特有更长的EF支持历史-从2007年8月30日开始。在这两年中，我们考虑了许多错误报告和用户请求。我们还创建和发布了我们的产品实体开发人员 -一个强大的设计时工具。

我们不能说我们对Oracle的实体框架支持是理想的--这个ORM最初是为MS SQL Server设计的，因此考虑到其他DBMS的奇迹的可能性是非常有限的。仅提及交叉应用和外部应用问题就足够了。

但是，尽管存在这些问题，我们的大多数用户仍然能够成功和舒适地使用实体框架。

这就足够了，但您已经提到了“关键的企业应用程序”。在本例中，我们建议您看看我们特定于Oracle的LINQ实现- LINQ到Oracle。

LINQ并不假装构建跨数据库解决方案，因此允许考虑单独DBMS (尤其是Oracle )的特性。与实体框架()不同的是，在LINQ情况下，我们只有部分控制生成的SQL查询，我们完全控制流程。这一事实使我们有机会生成快速有效的特定于Oracle的查询，并加快错误修复和改进过程。

对于遗留的Oracle数据库，EF通常很难应用，与LINQ不同。

使用LINQ模型的设计时间也使用实体开发人员执行。

在这里，延迟的反馈，但在一些测试，我们现在正在做的几十万行，DataDirect驱动是最快的-大约10倍的速度比MSFT驱动。DevArt也相当快，但只需几秒钟，那么它就会花费所有的时间来收集垃圾。在我们的示例中，原始选择速度的区别在于驱动程序如何将其值转换为.NET对象，而不一定能够以多快的速度将字节从线路上取出。