有没有人对 DevArt 的 dotConnect for Oracle 和 ADO.NET data provider from DataDirect 做过对比分析。
我们正在考虑将这些框架中提供的实体框架支持用于关键的企业应用程序。我读过的一些文章建议如下：
谁能更深入地了解技术方面以帮助决策过程？
【问题讨论】：
标签： oracle entity-framework ado.net devart dotconnect
这里有最新的反馈，但在我们现在正在加载数十万行的某些测试中，DataDirect 驱动程序是最快的 - 大约比 MSFT 驱动程序快 10 倍。 DevArt 也非常快，但只有几秒钟，然后它就将所有时间都用于垃圾收集。在我们的例子中，原始选择速度的区别在于驱动程序在将它们的值转换为 .NET 对象方面有多聪明，而不一定是它们可以多快地从线路中提取字节。
【讨论】：
由于无利害关系方的任何人尚未留下任何 cmets，我们将尝试发布尽可能中立的评论。
自 2007 年 8 月 30 日以来，Devart 的 EF 支持历史更长。在这两年中，我们考虑了许多错误报告和用户请求。我们还创建并发布了我们的产品Entity Developer - 一个强大的设计时工具。
我们不能将我们对 Oracle 的实体框架支持称为理想的支持 - 这个 ORM 最初是为 MS SQL Server 设计的，因此考虑其他 DBMS 的奇迹的可能性非常有限。
仅提及 CROSS APPLY 和 OUTER APPLY problem 就足够了。
但是，尽管存在这些问题，我们的大多数用户都能够成功且舒适地使用 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 执行。
【讨论】：