实体框架4与NHibernate
Dee*_*nky 112 .net nhibernate orm entity-framework
很多人已经在网上讨论过Entity Framework的第一个版本(也在stackoverflow上),很明显,当我们已经拥有像NHibernate这样的更好的替代品时,它不是一个好的选择.但我找不到实体框架4和NHibernate的良好比较.我们可以说今天NHibernate是所有.NET ORM中的领导者,但是我们可以期待Entity Framework 4从这个位置取代NHibernate.我认为如果微软真的在EF4中注入了非常好的功能,它可以给NHibernate带来很好的竞争,因为它具有Visual Studio集成,更易于使用,并且在大多数商店中总是优先考虑MS产品.
Joh*_*ner 65
EF4在"自我跟踪实体"中有关于n层开发的开箱即用的答案.没人发布NHib的可比代码.
NHib有很多未被提及作为EF4的一部分的功能.这些包括二级缓存集成.它还具有更大的继承映射灵活性,与存储过程/数据库函数/自定义SQL /触发器的更好集成,对公式属性的支持等.IMO它作为ORM基本上更加成熟.
- -1对于"EF4在n-tier开发方面有一个开箱即用的答案,在"自我跟踪实体"中.没有人发布过类似的NHib代码." 在NHibernate中有ISession.Merge,它比N-Tier开发的自跟踪实体要好得多,原因很多. (15认同)
- +1你是对的.NH刚刚成熟.EF将在今年年底前赶上.版本4.0已经进入了一个戏剧性的入口.给它一些时间,它将在2011年中期防弹. (13认同)
- @Alex - NHibernate以什么方式开箱即用"开箱即用"解决方案？只是为了澄清; ["开箱即用"](http://en.wikipedia.org/wiki/Out_of_the_box)表示它适用于Visual Studio的vanilla安装.那是一个不合理的-1. (12认同)
- @DoctaJonez - 我读它的方式,亚历克斯正在争论NH与自我跟踪实体没有任何可比性的想法,而不是关于它是"开箱即用"的部分. (9认同)
- 实际上,我发现EF4具有更灵活的继承映射.例如,您可以使用2个表(TPT)作为基类+ 1级类,并将判别器添加到1级表,允许拆分为2级类.在NH中,鉴别器只能在基类上定义. (2认同)
Ale*_*sev 37
更新:我从4.0版开始就没有使用Entity Framework,所以我的回答可能已经过时了.我仍然在我的项目中使用NH或纯ADO .NET.我甚至不想看看自4.0以来EF中的新功能,因为NH工作得很好.
当你使用两者时,实际上很容易比较它们.EF4有一些严重的限制,我可以说出我自己遇到的一些问题:
EF4问题:
- 渴望加载和整形结果:EF4 eager加载系统(包含("路径"))生成不正确的SQL,循环JOIN,对于多对多关系执行数千(非字面)时间慢,然后手写SQL(它是实际上无法使用).
- Materializer无法实现关联实体:如果您认为通过提供自己的SQL查询可以克服以前的问题,那么您就错了.EF4无法从JOIN SQL查询中实现(映射)关联实体,它只能从一个表加载数据(所以如果你有Order.Product,SELECT*FROM命令LEFT JOIN产品将只初始化Order对象,Product将保持为null,认为在查询中获取所有必要的数据以初始化它).这可以通过使用EFExtensions社区附加组件来克服,但您必须为此编写的代码非常难看(我试过).
自我跟踪实体:许多人说自我跟踪实体对于N层开发来说很酷,包括这个主题的最佳答案.以为我甚至都没试过,我可以说它们不是.每个输入都可以伪造,你不能简单地接受用户发送给你的更改并将它们应用到数据库,为什么不给用户直接数据基地访问呢？你将不得不加载数据用户的任何方式即将从DB更改,检查它是否存在,不存在权限检查等等.你不能信任用户对他发送到服务器的实体的状态,你还是会必须从数据库加载这个实体并确定它的状态和其他东西,所以这些信息是无用的,自我跟踪实体也是如此,除非你做一个私人信任的n层系统供内部使用,在这种情况下你可以给出简单的数据库访问.(多数民众赞成我关于ST实体和N轮胎的想法,我在N-Tier中没有经历过,所以它可以改变,如果我在这里误解了一些东西,请评论它)
记录,事件,集成业务逻辑: EF4就像黑盒子,它做了一些事情,你不知道它做了什么.只有一个事件OnSavingChanges,您可以在DB发生某些事情之前放置一些您需要运行的业务逻辑,如果您需要在事情发生之前对业务对象应用一些更改,您将不得不深入了解ObjectStateManager,这真的很难看,代码可以变得巨大.例如,如果您使用Repository模式以及以干净对象方式对DB所做的更改通知的内容,那么您将很难使用EF进行此操作.
可扩展性:所有EF代码都是私密的和内部的,如果你不喜欢某些东西(如果你认真对待EF使用你就不会喜欢),你决不会这么简单地改变它,事实上我确定从头开始编写自己的ORM(我做了)然后根据需要使EF工作更容易.作为示例,看一下EFExtensions源代码,它基于扩展方法,以及不同的"黑客"使EF更加可用,代码非常难看(并且这不是作者的错,当EF中的所有内容都是私有的时候这是唯一的扩展它的方式).
我可以继续写关于EF的不好的事情,对我来说,用20页来处理它是多么痛苦,也许我会.
NHibernate怎么样？这是完全不同的级别,就像比较PHP和C#,EF4就像Stone-age一样,它就像EF在开发进程中落后于NHibernate落后10年,事实上它是,Hibernate于2001年开始.如果你有空闲时间学习并打开Nhibernate,做到这一点.
- -1用于制作几个语句之前的"我还没用过这个,但我还在说话." (2认同)
- 您承认自己从未使用过自我追踪实体,但却解雇了它们.怎么样才能说出你所知道的东西,而忽略了无知的猜测,特别是因为整个段落都是错误的. (2认同)
zow*_*ens 25
这就是事情.在我看来,NHibernate和Entity Framework真的适合两个不同的受众.NHibernate将是我构建具有复杂映射,公式和约束(基本上是任何企业)的系统的选择.如果我想通过简单的数据访问实现运行,我会使用Entity Framework或LINQ-to-SQL.NHibernate没有像EF那样清晰的"拖放"体验.两者都有其优点和缺点.坦率地说,比较他们苹果对苹果,无处可去.
- -1这不是NHibernate与实体框架的良好比较.通过将EF与LINQ to SQL进行比较来比较两者,只有b/c它具有拖放性,最多是不诚实的.至于复杂性,NHibernate究竟能做到什么,EF 4无法做到？ (21认同)
- 二级缓存,他们的查询被高度优化,NH强制您使用UnitOfWork模式,加上映射不会卡在一个文件中.我的观点(来自经验)是NHibernate更高效.我不同意这一点,但我确实说过这是我的看法.我在答案中的观点仍然有效,他们两个都有自己的优点和缺点.没有人可以否认这一点. (14认同)
- 你试过ActiveWriter吗？实体框架绝对是企业领域的目标.我不同意你所说的大部分内容. (13认同)
- @ MakerOfThings7这很可悲......整个问题都是主观的.醒来... (2认同)
Joe*_*ler 23
如果你认为你可能想要在Mono上运行你的代码,那么NHibernate可能是一个更好的选择,无论功能清单说什么...
编辑,2012年8月13日:
实体框架是开源的,自2.11.3起包含在Mono中.这个答案现在已经过时,不应该依赖.
http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx
小智 12
我对此的看法是,自1.0以来EF4.0已经走了很长一段路,并且在功能上赶上了Nhibernate,但它还不是全部.
然而,开箱即用的是微软,它完成了95%的应用程序需要它做的100%.然而,NHibernate多年来一直在做同样的事情.5.0版或6.0版可能会赶上,甚至超越NHibernate.
这是我的建议 - 如果你有时间学习两者,那就去做吧.选择一个而不是另一个有几个原因.如果您正在为公司编写代码,那么期望能够熟悉EF的员工是可行的,就像在所有书籍中以及孩子在大学里学到的东西一样.如果EF能够满足你的要求(在说出肯定之前想想这个很长很难),那么现在它是一个非常好的解决方案,并且在几年内它可能(好吧,很可能会)超越NHibernate.
NHibernate是一款非常成熟的产品,在EF上用了几年时间,很可能会做你想做的一切,然后做一些.它现在已经是最好的ORM,并且很多人都使用它.
Yea*_*Stu 10
我认为EF 4能够使用POCO和延迟延迟加载的事实将非常大.我肯定能看到它在新版本中获得牵引力.
- 不要忘记LINQ支持.NHibernate仍然不擅长. (7认同)
- @Michael当您浏览Ayande关于该主题的博客文章时,这一点很明显.LINQ to NH基于目前的标准API.条件API不允许HQL可以使用一些更复杂的查询函数.LINQ to NH的下一个版本将使用HQL而不是标准API. (2认同)
| 归档时间： |
|
| 查看次数： |
37209 次 |
| 最近记录： |