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

Question

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

标准是:

Answer 1

使用以下内容:

我当然可以说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
- 骗局:沉重和依赖.使用这些ORM,您的业务对象现在可以直接绑定到ORM API.如果您想要更改为其他ORM怎么办？什么是防止初级开发人员滥用ORM API的高级功能来修复复杂解决方案的简单问题(我已经看到了这一点)？内存使用也是这些ORM的一个大问题.5000多个实体的集合可以轻松地使用上述ORM中的100MB RAM.序列化是另一个问题.随着对象的沉重,序列化可能会非常慢......并且它可能无法正确地在线路的另一端进行反序列化(WCF或.NET远程处理等).关联最终可能无法正确关联,或者某些字段可能无法保留.
重量轻
- 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以来,它已经有了很大的改进,除了开源之外,还支持你需要的一切:

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

没有合适的设计师,EF v4也不是真的可用.您登记的功能通常仅在编辑EDMX文件后才可用.我发现你的观点6.尤其不是很有说服力.但我有偏见,我知道;) (2认同)
@Frans:我想我应该期待LLBLGen之王的反驳.我已经阅读了你的博客一段时间了,虽然我不想这么说,但你经常对EF(以及L2S和LINQ)功能缺乏了解.与EF v1设计师的灾难不同,EF v4的设计师更加灵活.生成的代码可通过T4模板高度自定义.由于切换到v4,我从来没有编辑EDMX ......这是v1的常见问题.其次,使用仅代码,您甚至没有EDMX文件,并且消除了因EDMX而可能出现的任何问题. (2认同)