用MVC从头开始创建网站，哪种ORM更好，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宠物皮：

1. 不能只加载某些"类型"。例如，如果将Post和Location作为*..*，将Question作为Post类型，则无法检索Location，而只能检索Question。您必须急切地加载allPosts，或者使用匿名类型投影。总的来说，急切的加载是极其痛苦的。

2. 在无状态、POCO场景中更新现有实体上的关系同样，如果您有一个Post，它有许多Location，并且您想更改现有Post链接到的Location，那么使用MVC控制器操作并没有简单的方法。当您使用POCO时，为了让EF将关系视为modified，您实际上需要将其设置为已修改。但是如果你有POCO，关系通常是ICollection<TPOCO>，所以你没有这些内置的方法。当您执行Save时，您最终会在OSM的内部手动设置实体状态。我最终手动合并了中的实体，基本上是从左到右。

3. 没有语句的批处理我相信NHibernate支持这一点。这是EF的一个大问题，尤其是如果你想在一次旅行中更新多个对象。我通常最终会使用一个存储过程，从一开始就击败EF点。

4. 无法将查找表映射到枚举。好吧，所以这不是一个大问题，但这是一个令人讨厌的问题。查找表自然适合枚举，但EF根本不支持它——尽管从第一天起社区就发出了请求。不知道为什么这个没有放进去。