我知道这个问题可能有点危险，但我真的需要一些意见。
我们有我们的系统，这是一个网站（将是流行的门户网站，我们使用MVC3），在我来这里之前，我的其他合作伙伴选择了NHibernate作为他们的OR Mapper解决方案，他们开始编写标准查询等。。
现在团队更接近Linq方法，所以我们尝试在内置的Linq提供程序中编写查询。。问题是……它被可怕地改编了——实际上，你不能写非琐碎的查询，也不能得到Not supported exception。。。
我们决定这是最后一个可能的时刻，将我们的OR映射器更改为更基于Linq的东西，由于EF4.1获得了超友好的代码优先选项，我们决定这就是我们所需要的。
我需要一些意见的问题是值得花时间从NHibernate迁移到EF4.1…该项目将在开发中持续至少一年，所以我们有很多工作要做，我们希望以一种既好又不令人沮丧的方式来做。。
一些事实：
- 我们的项目中有大约50个实体
- 我们有大约160个用Criteria API编写的查询（全部包含在单元测试中）
- 我们需要复合、继承和许多支持
- 这个项目将是现在的两倍大
- 我们对数据库性能不满意
- 我们讨厌现在编写查询的方式
所以。。现在迁移是个好主意还是坏主意？英孚会解决我们的问题吗？它会让我们高兴吗？还是这一步只是浪费我们的时间？
问候
请注意，您将用更好的linq支持来交换更差的映射功能，有时甚至更差的性能（继承查询、无查询或命令批处理等）。现在返回黑板，重新思考。如果你现在不喜欢你的数据库性能，那么EF很难改善它。
我想现在改变这项技术有点晚了——它的成本会很高。但无论如何，如果你真的想这样做，为什么不做概念验证呢？你可以用一些高级查询来获得一些非常复杂的映射特征，并尝试首先在EF代码中这样做？您可以在简单的控制台应用程序中测试相同的功能，并比较映射体验和查询+性能。
性能目前可能不是问题，但它可能是你未来真正需要优化的东西，EF将为你提供更少的功能。如果您想提高EF解决方案的性能，您通常会恢复到本机SQL和存储过程。你认为它在编写查询方面会有更好的体验吗？
我不得不同意@Ladislav的观点，EF和LINQ很好，与NHibernate LINQ相比，它只是起作用，但SQL EF生成的有时非常糟糕，性能也不太好，您将被迫将复杂的查询重新编码为视图和SP等。Nhibernate也可能陷入这个陷阱，但有许多不同的选择是一个好处，因为你可以根据自己的需求挑选最好的。
我想你正在考虑平衡以下方面：-
- 使用EF重写，然后将丑陋/缓慢生成的SQL修改为更高性能的数据库查询
- 使用NHibernate并将任何过于复杂的LINQ放入Criteria/QueryOver/HQL
有点像从煎锅跳到火里。两者都有各自的优点，都会灼伤你的手指！
就我个人而言，我也遇到了Nhibernate的linq提供程序的问题。
然而，我选择坚持使用NHibernate，因为它的SQL生成"正确"，整体性能和可扩展性。
后者允许您使用自己选择的二级缓存（如MemcacheD）来缓解RDBMS。它将对象保持在内存中（在MemcacheD服务器上），仅在需要时从RDBMS获取/提交对象。也适用于已编译的SQL查询。
老实说，听起来你已经下定决心了。我不知道你到底在问什么。如果你有兴趣坚持使用NHibernate，你应该就你遇到的问题提出具体的问题。
在我看来，如果你的团队更熟悉EF，那么你应该换一个。如果他们没有，那么我不确定你是否会知道EF是否会解决你的所有问题，除非你真正概述了你遇到的具体问题。
您尝试过Fluent NHibernate吗？http://fluentnhibernate.org/.你可以把LINQ和它一起使用。我在一个项目中使用过它，效果很好。