有没有人对 DevArt 的 dotConnect for Oracle 和DataDirect 的 ADO.NET 数据提供程序进行比较分析。
我们正在考虑将这些框架中可用的实体框架支持用于关键企业应用程序。我读过的一些文章建议如下:
- 与 DataDirect 相比,DevArt dotConnect 快得多
- DataDirect 许可证比 DevArt 许可证更贵
任何人都可以更多地了解技术方面以帮助决策过程吗?
有没有人对 DevArt 的 dotConnect for Oracle 和DataDirect 的 ADO.NET 数据提供程序进行比较分析。
我们正在考虑将这些框架中可用的实体框架支持用于关键企业应用程序。我读过的一些文章建议如下:
任何人都可以更多地了解技术方面以帮助决策过程吗?
由于无利害关系方尚未发表任何评论,我们将尽量发表中立评论。
自 2007 年 8 月 30 日以来,Devart 的 EF 支持历史更长。在这两年中,我们考虑了许多错误报告和用户请求。我们还创建并发布了我们的产品Entity Developer - 一个强大的设计时工具。
我们不能将我们对 Oracle 的实体框架支持称为理想的支持 - 这个 ORM 最初是为 MS SQL Server 设计的,因此考虑其他 DBMS 的奇迹的可能性非常有限。仅提及 CROSS APPLY 和 OUTER APPLY问题就足够了。
但是,尽管存在这些问题,我们的大多数用户都能够成功且舒适地使用 Entity Framework。
这足以说明,但您已经提到了“关键的企业暗示”。在这种情况下,我们建议您查看我们的特定于 Oracle 的 LINQ to SQL 实现 - LINQ to Oracle。
LINQ to SQL 不假装构建跨数据库解决方案,因此允许考虑单独 DBMS 的特性,特别是 Oracle。与我们只能部分控制生成的 SQL 查询的 Entity Framework 不同,在 LINQ to Oracle 案例中,我们可以完全控制该过程。这一事实使我们有机会生成快速有效的 Oracle 特定查询,并加快错误修复和改进过程。
在遗留 Oracle 数据库的情况下,EF 通常很难应用,这与 LINQ to Oracle 不同。
使用 LINQ to Oracle 模型的设计时工作也使用 Entity Developer 执行。
这里有最新的反馈,但在我们现在正在加载数十万行的一些测试中,DataDirect 驱动程序是最快的——大约比 MSFT 驱动程序快 10 倍。DevArt 也非常快,但只有几秒钟,然后它就将所有时间都用于垃圾收集。在我们的例子中,原始选择速度的区别在于驱动程序在将它们的值转换为 .NET 对象方面有多聪明,而不一定是它们可以多快地从线路中提取字节。