请推荐用于N层开发的.NET ORM

Question

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

标准是：

1. db模式映射到对象的灵活性（首选）
2. 易用性
3. 免费，开源（首选）
4. 必须适合N层（多进程多域应用程序）
5. 性能
6. 与Visual Studio集成的工具（首选）
7. 可测
8. 采用，提供文件
9. 支持广泛的RDBMS（首选;我们使用的是MSSQL，但我不想与它绑在一起）
10. DB不可知 - 不同的DB，相同的API

Answer 1

使用了以下内容：

• NHibernate的

• LLBLGEN

• 实体框架

• LINQ to SQL

• DataObjects.Net

• 的OpenAccess

• 数据表

我可以肯定地说DataTables是优越的......不仅仅是开玩笑。所有这些都有自己的优点和缺点。

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

• 重重量

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

  • Pro：利用内置API在运行时与实体本身进行交互（即来自LLBLGen entity.Fields [“MyField”]。更新更容易，更快速开发.IsChanged或entity.IsNew或entity.Fields [ “MyField的”]。DbValue

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

• 轻量

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

  • 专业版：轻量级。保持简单。 ORM不可知的业务对象。

  • Con：较少的功能，例如实体图形维护，状态跟踪等。

无论你选择什么样的ORM，我个人的偏好都是坚持使用LINQ和ORM独立的检索语法（不是ORM自己提取的API，如果有的话）。

关于所提到的具体问题，以下是我的简要介绍： - NHibernate：技术明智的时代背后。大量的xml映射文件的维护（虽然Fluent NHibernate确实缓解了这一点）。

• LLBLGen：我与之合作过的最成熟的ORM。轻松启动新项目并开始工作。最佳设计师。非常重的。丰富的非常强大的API。我遇到过的最佳速度。因为它不是块中的新手，所以利用新技术的一些新功能并没有得到应有的实现（LINQ专门）。

• 实体框架：4.0中的POCO类看起来很有前途。 3.5没有这个，我甚至不会考虑它。即使在4.0中，也没有很好的LINQ支持并且生成不良的SQL（可以为单个LINQ查询生成数百个数据库查询）。对于大型项目，设计师支持很差。

• LINQ to SQL：出色的LINQ支持（优于除DataObjects.Net之外的任何其他）。平庸持久性（保存/更新）支持。非常轻便（POCO）。设计器支持很差（没有从DB刷新）。高级LINQ查询性能不佳（可以进行数百次数据库查询）

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

• OpenAccess：没有使用过它，但它让我想起了LLBLGen，但不是功能丰富或成熟。

• DataTables：无评论

Answer 2

为什么不试试NHibernate？

Answer 3

我会推荐Entity Framework v4。自v1以来，它已经有了很大的改进，除了开源之外，还支持你需要的一切：

1. EF支持各种映射，包括TPH，TPT和TPC。支持POCO映射，允许您将持久性逻辑与您的域分开。
2. EF为LINQ提供了广泛而出色的支持，为您的模型提供了易于使用，编译时检查的查询。 EF Futures组件如Code-Only简化了EF的工作，提供了纯代码，编译时检查，用于定义模型的流畅API。通过选择约定优于配置，Code-Only可以从根本上缩短您的模型设计时间，使您无需修改​​可视化模型和多个XML映射文件即可开展业务。
3. 它是.NET 4的一部分免费。（抱歉，这里无法满足开源偏好。）
4. EF通过self-tracking entities提供出色的N-Tier解决方案OOB
   • 自我跟踪信息使用开放的xml格式传输跟踪数据，因此跟踪支持可以添加到非.NET平台
5. EF v4的性能非常好，因为在查询生成器上进行了大量工作
   • 请参阅主题的ADO.NET Blog entry
6. EF提供了极其丰富的可视化设计工具，并允许通过自定义T4 templates and workflows
进行大量自定义代码生成
7. EF v4引入了众多接口，包括IObjectSet<T>和IDbSet<T>接口，极大地提高了自定义上下文的单元可测试性
8. EF v4是.NET 4不可或缺的一部分，也是所有Microsofts当前和未来数据计划的核心组成部分。作为.NET的一部分，它的文档非常广泛：MSDN，EFDesign Blog，ADO.NET Blog，数十个.NET和编程站点和博客为该平台提供了大量的文档和支持。

Answer 4

EF的另一次投票。

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

• 支持LINQ，这样如果正确编写LINQ，它只会转换发送到服务器的单个SQL语句。

Answer 5

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

  

LightSpeed是最好的高性能.NET域建模和O / R映射框架。一流的LINQ支持，Visual Studio 2008＆amp; 2010年设计师集成和我们着名的高性能核心框架意味着您可以比以往更快速，更轻松地创建丰富的域驱动模型。

Answer 6

在几个项目中使用过OpenAccess，我必须说它符合上述所有标准。 我工作的一个系统基于与几种客户端类型（智能，Web，其他WCF服务等）通信的WCF服务。通过分层体系结构，WCF服务使用OpenAccess作为持久性机制。 我特别喜欢OpenAccess执行的扩展。智能二级缓存（二级缓存）在那里做得非常完美，它是可分发的。 实际上我不会称OA为重量级......你甚至不从基类继承。此外，有一些工具可以执行集成到visual studio中的日常开发人员任务（创建新的数据库模式，合并模式等）。

Answer 7

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

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

2 - 当表的数量增长时，设计师非常慢。 45秒只是为了在具有240个实体的模型中折叠/扩展实体。

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

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