我想创建一个网站,有很多用户,显然有大量的数据库,而且我没有EF或NHibernate的经验,推荐给我什么?
EF与.NET和Visual Studio的集成非常好。在VisualStudio中为您提供了一个非常好的设计器,并利用LINQ编写易于阅读的查询。
对我来说,这是一件很容易的事。毫无疑问,我会选择EF4。
如果你是第一次这样做,我建议你使用EF,因为它很容易玩,没有更多的配置和隐藏属性。。。。不需要付出任何额外的努力,只需添加对象,您的任务就完成了。
但如果你想要更好的表现,那就去NHibernate。
答案取决于您在后端使用的数据库。如果你正在使用任何一个微软数据库,那么EF就是你的选择。
Oracle还没有支持EF的客户端(即将推出),因此您需要使用NHibernate与Oracle对话,直到他们更新客户端。
我会选择NHibernate,因为它可以让你比EF更好地调整性能,并且在不同的数据库中更容易移植。
当第一次使用asp.net mvc时,可以考虑使用S#arp架构。它使用NHibernate。网站上清楚地解释了如何快速入门。
两者都没有。
在过去的一年里,我一直在使用EF,我遇到的问题不值得这么麻烦。
我已经告诉我的同行们这一点——如果我能回到过去,我将使用带有精简API的存储过程来抽象它。
要么这样,要么使用像Dapper或Massive这样的"轻量级"ORM。
EF给了我太多的膨胀、关联的复杂性(尤其是继承模型)、从未修复的bug,以及在MVC等无状态环境中"更新"实体的问题。
真的不在乎我是否被否决了——只想投入我的两分钱。最初我喜欢EF,因为我来自L2SQL背景,所以这是一个简单的过渡。但当我开始在掩护下挖掘时,我发现与之一起工作是多么痛苦。
话虽如此,我还没有使用NHibernate,所以我不能对此发表评论,只能评论实体框架。
紧紧抓住金属——从长远来看,你会得到更好的表现。在"真实"模型SQL中编写代码,使用索引,让SQL Server(或Oracle)的引擎做它最擅长的事情。
尽管LINQ框架是一致的和智能的,IMO(这就是我们在这里所能做的,给出意见),但当你有一个非基本模型时(大多数人都会这样做),LINQ实体并不能生成足够好的SQL。
我的EF4宠物皮:
-
不能只加载某些"类型"。例如,如果将
Post
和Location
作为*..*
,将Question
作为Post类型,则无法检索Location
,而只能检索Question
。您必须急切地加载allPosts
,或者使用匿名类型投影。总的来说,急切的加载是极其痛苦的。 -
在无状态、POCO场景中更新现有实体上的关系同样,如果您有一个
Post
,它有许多Location
,并且您想更改现有Post
链接到的Location
,那么使用MVC控制器操作并没有简单的方法。当您使用POCO时,为了让EF将关系视为modified
,您实际上需要将其设置为已修改。但是如果你有POCO,关系通常是ICollection<TPOCO>
,所以你没有这些内置的方法。当您执行Save
时,您最终会在OSM的内部手动设置实体状态。我最终手动合并了中的实体,基本上是从左到右。 -
没有语句的批处理我相信NHibernate支持这一点。这是EF的一个大问题,尤其是如果你想在一次旅行中更新多个对象。我通常最终会使用一个存储过程,从一开始就击败EF点。
-
无法将查找表映射到枚举。好吧,所以这不是一个大问题,但这是一个令人讨厌的问题。查找表自然适合枚举,但EF根本不支持它——尽管从第一天起社区就发出了请求。不知道为什么这个没有放进去。