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

2022-01-23 00:00:00 oracle entity-framework ado.net devart dotconnect

有没有人对 DevArt 的 dotConnect for Oracle 和 ADO 做过比较分析来自 DataDirect 的 .NET 数据提供程序.

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. 与 DataDirect 相比，DevArt dotConnect 更快
  2. DataDirect 许可比 DevArt 许可更昂贵

谁能更深入地了解技术方面以帮助决策过程?

推荐答案

由于没有来自无利害关系方的人尚未发表任何评论，我们将尽量发表中立评论.
自 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 执行.

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.

相关文章