我们即将开始一些ASP.NET MVC开发，并且多年来一直在使用我们自己的实体框架。但是我们需要支持的不仅仅是我们的实体框架能够支持，所以我想得到一些关于使用MVC和更强大的框架的意见。我们已经缩小或选择NHibernate（使用Fluent API）或LINQ to SQL。
哪种框架最适合MVC风格开发（我知道SO使用LINQ to SQL）？
如果我们想要支持SQL Server，Oracle，MySQL - 它会排除LINQ to SQL吗？
答案 0 :(得分：6)
作为刚刚从LINQ to SQL切换到（流利）NHibernate的人，这里有一些我注意到的事情。
LINQ to SQL花了很长时间才弄清楚如何做一个等效的join-subclass。经过多次修改后，我在某处读到了这是不可能的。如果所有列都在同一个表中，它只能映射继承。如果有几列，这很好，但在我的情况下有很多，子类是其他子类的父类，依此类推。为了我的ORM，为什么要把它们全部放在一张桌子里？
来自经验的NHibernate一直很强大（对于小型快速项目来说有时太多了）虽然通过小项目熟悉它，但我觉得它可能太多了，因为我可以生成一个LINQ to SQL的路径DBML档案并在几分钟内完成。
流利的NHibernate。充分利用两个世界（在我的情况下）。我可以按照我想要的方式映射，并以我想要的方式拥有我的数据库，而不必在我的域或数据模型中妥协。还有一个词：自动化......锦上添花。
一旦我发现了限制并且使用LINQ to SQL遇到了一些障碍，我将不得不使用另一个ORM，但是Fluent NHibernate使这个选择很容易，我不认为我会留下它，除非出现问题这项工作做得更好。
所以，就像Rob Scott所说，问题是你是如何抽象你的域名=＆gt;数据模型？您是从域名还是数据库开始的？关系有多复杂？如果你有任何继承权，我会说只需要使用更丰富的ORM框架并为自己保留悲伤。
流利的NHibernate拥有一些我见过的最好的文档，并且有很多支持，笔记，博客和资源，它们自我厌恶做任何事情...... IMO！我不到24小时就开始跑步了。
哦，如果你是NHibernate的新手拿起NHibernate in Action书来帮助润滑车轮，尽管这个框架也有很多帮助。
工具无效的最佳指示是当你必须使用工具时... LINQ to SQL我正在定制，阅读白皮书，各种疯狂并拒绝生成适当的查询，就在我很想改变我的桌子和领域，我说让我给Fluent一个旋转，我很高兴我做到了。
祝你好运..对不起，回复很久;这已经过去了五天左右，所以我想我还是赶上了： - ）
答案 1 :(得分：4)
我使用Fluent NHibernate和依赖注入（在我的例子中为Ninject）与MVC取得了巨大的成功。
在我看来，任何成熟的ORM都应该适用于MVC。由于MVC（模型/视图/控制器）的性质将这三个问题分开，因此任何ORM都应该非常适合“模型”角色。
答案 2 :(得分：2)
LINQ to SQL适用于SQL Server。实体框架也支持其他一些数据库。
NHibernate是不错的选择。如果您正在进行基于数据的应用程序，则可以使用Castle ActiveRecord（它构建在NH之上）或Sharp Architecture用于项目指导。
答案 3 :(得分：1)
实体框架与MVC很好地集成，并支持其他数据库。
答案 4 :(得分：1)
简短（并没有那么有帮助）的答案是你提到的两个ORM都适用于MVC。更长的答案是您应该考虑如何使用模型对象。例如，您是要进行域对象优先开发（ala a Domain Driven Design方法），还是要实现“表单数据”类型的应用程序，您可能希望从现有数据库生成数据访问层？您对指定映射的偏好是什么？您想使用流畅的界面，还是对映射文件（或域对象的属性）感到满意？
这些是您在选择ORM时需要调查的问题类型 - 它们主要与您使用MVC还是Winforms无关。
答案 5 :(得分：0)
Entity Framework使事情复杂化。在控制器中使用Fluent NHibernate，Repository模式和inversion of control。
NHibernate将使许多事情变得更容易。我们最近从Entity Framework迁移到Fluent Nhibernate，而Fluent NHibernate绝对是更好的候选者。