请为 N 层开发推荐 .NET ORM [关闭]

Posted 2023-04-12

【中文标题】请为 N 层开发推荐 .NET ORM [关闭]

【英文标题】：Please recommend .NET ORM for N-tier development [closed]

【发布时间】：2010-07-15 01:29:19

【问题描述】：

我需要为 N 层应用程序仔细选择 .NET ORM。 这意味着，我将拥有公开数据的服务器（WCF 服务）和显示数据的客户端。 ORM 应该顺利地支持所有相关的序列化问题——对象或对象集合，或者任何必须跨越进程边界的东西。理想情况下，多进程环境下的使用应该和单进程一样。

标准是：

数据库模式映射到对象的灵活性（首选） 易于使用 免费、开源（首选） 必须适合N层（多进程多域应用） 性能 与 Visual Studio 集成的工具（首选） 可测试性 采用、文档的可用性 支持范围广泛的 RDBMS（首选；我们使用的是 MSSQL，但我不想被绑定） 与数据库无关 - 不同的数据库，相同的 API

【问题讨论】：

***.com/questions/1377236/…

【参考方案1】：

曾与以下人员合作过：

NHibernate

LLBLGen

实体框架

LINQ to SQL

DataObjects.Net

开放存取

数据表

我可以肯定地说 DataTables 更胜一筹……不只是在开玩笑。他们都有自己的长处和短处。

我发现这些优势和劣势主要与ORM的一般类型有关，分为以下两类

重量级

LLBLGen、OpenAccess、Entity Framework（4.0 之前）、DataObjects 都属于这一类。重量级 ORM 通常具有继承自特定于 ORM 的基类（即 EntityBase）的实体和集合。这些 ORM 通常提供丰富的设计时支持、代码生成和深入的运行时特性（例如状态跟踪、事务跟踪、关联维护等）。

专业人士：利用内置 API 在运行时与实体本身交互（即来自 LLBLGen entity.Fields["MyField"].IsChanged 或 entity.IsNew 或 entity.Fields[ "MyField"].DbValue

骗局：沉重和依赖。使用这些 ORM，您的业务对象现在直接绑定到 ORM API。如果你想换成另一个 ORM 怎么办？还有什么可以防止初级开发人员滥用 ORM API 的高级功能来解决复杂解决方案的简单问题（我已经看到很多）？内存使用也是这些 ORM 的一个大问题。使用上述一些 ORM，5,000 多个实体的集合可以轻松占用 100MB 的 RAM。序列化是另一个问题。由于对象的繁重，序列化可能非常慢......并且它可能无法在线路的另一端正确反序列化（WCF 或 .NET 远程处理等）。关联最终可能无法正确重新关联，或者某些字段可能无法保留。上面的几个 ORM 已经内置了序列化机制来提高支持和速度......但我见过的没有一个提供对不同格式的完全支持（即你得到二进制，但没有 json 或 xml 序列化支持）。

轻量级

LINQ to SQL、实体框架 POCO、NHibernate（有点）属于这一类。轻量级 ORM 通常使用 POCO，您可以在 VS 中的文件中自行设计（当然您也可以使用 T4 模板或代码生成器）。

专业版：轻量级。保持简单。与 ORM 无关的业务对象。

缺点：更少的功能，例如实体图维护、状态跟踪等。

不管你选择什么 ORM，我个人的偏好是坚持使用 LINQ，以及独立于 ORM 的检索语法（不是 ORM 自己的获取 API，如果有的话）。

关于具体提到的，以下是我的简要想法： - NHibernate：技术落后时代。 xml 映射文件的大量维护（尽管 Fluent NHibernate 确实缓解了这一点）。

LLBLGen：我使用过的最成熟的 ORM。轻松启动新项目并开始工作。最佳设计师。很重的重量。丰富非常强大的API。我遇到的最好的速度。因为它不是新事物，所以利用新技术的一些新功能没有按应有的方式实现（特别是 LINQ）。

实体框架：4.0 中的 POCO 类看起来很有希望。 3.5没有这个，我什至不会考虑。即使在 4.0 中，也没有很好的 LINQ 支持并生成较差的 SQL（可以为单个 LINQ 查询进行数百个 DB 查询）。当涉及到较大的项目时，设计师的支持很差。

LINQ to SQL：出色的 LINQ 支持（比 DataObjects.Net 以外的任何其他软件都好）。平庸的持久性（保存/更新）支持。非常轻巧（POCO）。设计器支持很差（数据库没有刷新）。高级 LINQ 查询性能不佳（可以进行数百个数据库查询）

DataObjects.Net：非常棒的 LINQ 支持和性能。在重量级 ORM 中提供了我见过的最接近 POCO 的东西。真正新的、强大的、有前途的技术。非常灵活。

OpenAccess：使用它的时间不多，但它让我想起了 LLBLGen，但功能并不丰富或成熟。

数据表：无评论

【讨论】：

数据表？你什么意思？ System.Data.DataTable?

我认为你应该重新分类实体框架 POCO。它当然不是您所描述的“轻量级”框架。即使将 POCO 与 EF v4 一起使用，您也可以使用 EF 的全部功能......您不会失去任何东西，但不会招致像 LLBLGen 这样的“重量级”框架的麻烦。如果您使用纯代码，则尤其如此。您对 EFv4 的 LINQ 和 SQL 支持的描述也很离谱……您描述了 EFv1 的 SQL 查询和 LINQ 支持……EFv4 得到了根本性的改进。

我强烈反对我的 EF 描述被关闭。我上周尝试执行以下操作： 1. 在投影中包含 Enum 值。我在示例中看到了这一点，它适用于 LINQ to SQL。在 EF 4.0 中，我得到一个无效的强制转换异常。 2. 一个嵌套子查询连接到主查询的一个属性上。 LINQ to SQL 可以工作，但每个子查询实例发出一个查询），因此性能非常差。 EF 4.0 根本不起作用。引发关于嵌套子查询是常量的异常。 DataObjects .Net 是我见过的唯一一个执行嵌套子查询场景并具有良好性能的 ORM。

@Dmitry - 是的，我见过人们将它们用作业务对象。

@jrista：纯代码非常不成熟。

【参考方案2】：

为什么不试试NHibernate？

【参考方案3】：

我会推荐实体框架 v4。自 v1 以来，它已经有了显着的改进，并且支持你需要的一切，除了开源：

EF 支持非常广泛的映射，包括 TPH、TPT 和 TPC。支持POCO 映射，允许您将持久性逻辑与您的域分开。 EF 对 LINQ 提供广泛而出色的支持，提供易于使用的、编译时检查的模型查询。 EF Futures 组件（例如Code-Only）进一步简化了与 EF 的合作，提供纯代码、编译时检查、流畅的 API 来定义您的模型。通过选择约定而不是配置，Code-Only 可以从根本上减少您的模型设计时间，让您无需费心地修改可视模型和多个 XML 映射文件即可开始工作。 它作为 .NET 4 的一部分是免费的。（抱歉，此处无法满足开源偏好。） EF 通过self-tracking entities 提供出色的 N 层解决方案 OOB

自追踪信息使用开放的xml格式传输追踪数据，因此非.NET平台可以添加追踪支持

EF v4 的性能非常好，因为在查询生成器上做了大量工作

请参阅ADO.NET Blog entry 的主题

EF 提供极其丰富的可视化设计工具，并允许通过自定义T4 templates and workflows 进行代码生成的广泛自定义 EF v4 引入了许多接口，包括 IObjectSet<T> 和 IDbSet<T> 接口，它们极大地提高了自定义上下文的单元可测试性 EF v4 是 .NET 4 的组成部分，也是 Microsoft 当前和未来所有数据计划的核心组件。作为 .NET 的一部分，它的文档非常丰富：MSDN、EFDesign Blog、ADO.NET Blog、数十个 .NET 和编程站点和博客为平台提供了大量文档和支持。

【讨论】：

如果没有合适的设计器，EF v4 也不是那么实用。您征用的功能通常只有在编辑 EDMX 文件后才能使用。我发现你的第 6 点。尤其不是很有说服力。但我有偏见，我知道 ;)

@Frans：我想我应该期待 LLBLGen 之王的反驳。我已经阅读您的博客一段时间了，虽然我不想这么说，但您经常表现出对 EF（以及 L2S 和 LINQ）功能的理解不足。 EF v4 的设计器与 EF v1 设计器的灾难不同，它更加灵活。生成的代码可通过 T4 模板进行高度定制。自从切换到 v4 后，我再也不用编辑 EDMX 了……这是 v1 的一个常见问题。其次，使用 Code-Only，您甚至没有 EDMX 文件，并且消除了任何可能因 EDMX 而出现的问题。

关于第 6 点，ADO.NET 博客上的以下博客条目介绍了使用 T4 模板和 Windows 工作流来自定义生成：blogs.msdn.com/b/adonet/archive/2009/11/05/…

它可能已经忽略了您的注意，但 llblgen pro v3 支持 EF v4（和 v1），并且当我编写了所有支持代码时，我确实对它了解很多；）请看这个视频： weblogs.asp.net/fbouma/archive/2010/04/28/… EF v4 设计器可能适合您，我希望看到您首先在模型中使用它，并使用 100 多个表系统。代码优先远未完成，我不认为这是一个论点。你似乎很喜欢 EF，很好，但请现实一点。就是这样。

【参考方案4】：

这里又给 EF 投票了。

非常容易进行单元测试。您可以编写自己的域实体，并使用POCO approach 让它们合理地摆脱持久性意识。然后，您可以在没有实际数据库的情况下模拟数据库接口并测试应用程序逻辑。

支持 LINQ，因此如果您正确编写 LINQ，它只会翻译发送到服务器的单个 SQL 语句。

【参考方案5】：

我一直在使用一个名为LightSpeed 的产品，它运行良好，并且可以无缝集成到 Visual Studio 2010 和 2008 中。我一直将它与 Sqlite 一起使用，但是它支持大量 rdbms。它还有一个非常好的功能，允许您创建可与 WCF 一起使用的 POCO 对象，非常节省时间！起初我使用的是免费的 Express Edition，但很快就升级了。

LightSpeed 是可用的最佳高性能 .NET 域建模和 O/R 映射框架。一流的 LINQ 支持、Visual Studio 2008 和 2010 设计器集成以及我们著名的高性能核心框架意味着您可以比以往更快、更轻松地创建丰富的领域驱动模型。

【参考方案6】：

在多个项目中使用过 OpenAccess，我必须说它符合上述所有标准。 我工作的一个系统是基于 WCF 服务与几种客户端类型（智能、Web、其他 WCF 服务等）对话的。通过分层架构，WCF 服务使用 OpenAccess 作为持久性机制。 我特别喜欢 OpenAccess 执行的缩放功能。智能 2 级缓存（L2 缓存）在那里做得很好，而且它是可分发的。 实际上，我不会称 OA 重量级...您甚至不从基类继承。此外，Visual Studio 中集成了执行日常开发人员任务（创建新的 DB 模式、合并模式等）的工具，这也是一大优势。

【参考方案7】：

关于 EF4... 请不要在大型​​项目中使用它，其中包含许多表和大量数据以及许多用户。我犯了这个错误，现在我正在寻找替代品。

1-查询生成错误，尤其是在大型 TPT 层次结构中。为 15 个表的层次结构的 5000 行查询做好准备！

2-当表格数量增加时，设计器速度极慢。只需 45 秒即可在具有 240 个实体的模型中折叠/展开实体。

3-x 对多关系的严重问题。假设您有 Order 和 Customer 实体。每个订单都有一个客户，每个客户有很多订单。在Customer 类中有一个名为Orders 的属性，无需您实际需要该数据即可填充该属性。这意味着，在我们的系统中，最多可以获取 1800000 个实体的集合，而无需任何实际原因。当这种情况发生在具有快照隔离级别的事务中时......这会使整个系统出现故障。这个问题没有实际的解决方案，没有严重的缺点。只需阅读 DataObjects.Net 的文档，看看他们是如何解决这个问题的。我发现与你得到的相比，支付 200 或 500 欧元根本不算什么。我什至可以得到带有源代码的版本。

如果我无法将我的系统与 DO.Net 集成，我会寻找另一个，但这个 EF 的东西，它必须走！