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

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

标准是:

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

我推荐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通过自跟踪实体提供出色的N层解决方案OOB
    • 自跟踪信息使用开放的xml格式来传输跟踪数据,因此可以将跟踪支持添加到非.NET平台
  5. EF v4的性能非常好,因为在查询生成器上进行了大量工作
    • 请参阅有关该主题的ADO.NET博客条目
  6. EF提供了极其丰富的可视化设计工具,并允许通过自定义T4模板和工作流程进行广泛的代码生成自定义
  7. EF v4引入了许多接口,包括IObjectSet 和IDbSet 接口,这极大地提高了自定义上下文的单元可测试性
  8. EF v4是.NET 4不可或缺的一部分,也是所有Microsofts当前和未来数据计划的核心组件。 作为.NET的一部分,它的文档非常广泛:MSDN, EFDesign博客 , ADO.NET博客 ,数十个.NET和编程站点和博客为该平台提供了大量的文档和支持。

使用以下内容:

  • NHibernate的

  • LLBLGEN

  • entity framework

  • LINQ to SQL

  • DataObjects.Net

  • 的OpenAccess

  • 数据表

我当然可以说DataTables更优越……不仅仅是开玩笑。 所有这些都有自己的优点和缺点。

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

  • 重量级

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

    • Pro:利用内置API在运行时与实体本身进行交互(即来自LLBLGen entity.Fields [“MyField”] .IsChanged或entity.IsNew或entity.Fields [“MyField”] .DbValue

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

  • 重量轻

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

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

    • Con:较少的function,例如实体图形维护,状态跟踪等。

无论你选择什么样的ORM,我个人的偏好都是坚持LINQ和ORM独立的检索语法(不是ORM自己的用于获取的API,如果有的话)。

关于提到的具体问题,以下是我的简短想法: – NHibernate:时代背后的技术明智。 大量的xml映射文件的维护(虽然Fluent NHibernate确实缓解了这一点)。

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

  • entity framework:4.0中的POCO类看起来很有前途。 3.5没有这个,我甚至不会考虑它。 即使在4.0中,也没有很好的LINQ支持并且生成的SQL很差(可以为单个LINQ查询生成数百个数据库查询)。 对于大型项目,设计师支持很差。

  • LINQ to SQL:很棒的LINQ支持(比DataObjects.Net更好的除外)。 平庸的持久性(保存/更新)支持。 非常轻便(POCO)。 设计师支持很差(没有刷新数据库)。 高级LINQ查询性能不佳(可以进行数百次数据库查询)

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

  • OpenAccess:没有使用过它,但它让我想起了LLBLGen,但并不像function丰富或成熟。

  • DataTables:没有评论

为什么不试试NHibernate ?

这里对EF的另一次投票。

  • 非常容易unit testing。 您可以编写自己的域实体,并使用POCO方法使它们合理地免于持久性感知 。 然后,您可以模拟数据库接口并测试应用程序逻辑,而无需实际数据库。

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

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

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

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

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

1 – 错误的查询生成,尤其是在大型TPT层次结构中。 准备5000行查询15个表的层次结构!

2 – 当表的数量增长时,设计器速度极慢。 45秒只是为了在具有240个实体的模型中折叠/扩展实体。

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

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