我知道这个问题可能有点危险，但我真的需要一些意见。
我们有我们的系统，它是一个网站（将是流行的门户网站，我们使用MVC3），在我来到这里之前，我的其他同事选择了NHibernate作为他们的OR Mapper解决方案，他们开始编写标准查询等等..
现在团队更接近Linq方法，所以我们尝试在内置的Linq提供程序中编写查询。事情是......它非常适应 - 字面上你不能写非平凡的查询而不能得到{{ 1}} ...
我们认为这是最后一个可能的时刻，将我们的OR Mapper更改为更基于Linq的东西，而且自从EF4.1获得了非常友好的Code First选项后，我们决定这就是我们需要的。
我需要一些意见的问题是值得花时间从NHibernate迁移到EF4.1 ......该项目将至少持续一年的开发，所以我们有很多工作要做，并且我们希望以愉快和非挫折的方式做到这一点。
一些事实：
那么......现在..迁移是一个好主意还是坏主意？ EF会解决我们的问题，它会让我们感到高兴，还是这一步只会浪费我们的时间？
此致
答案 0 :(得分：12)
请注意，您将更好地更换linq支持更糟糕的映射功能，有时甚至更差的性能（inheritance queries，no query or command batching，...）。现在回到黑板上再想一想。如果您现在不喜欢数据库性能，那么使用EF几乎不会改善。
我想改变技术有点迟了 - 它会有很高的成本。但无论如何，如果你真的想要这样做，为什么不进行概念验证，你可以在一些高级查询中使用一些非常复杂的映射功能，并尝试在EF代码中先做同样的事情？您可以在简单的控制台应用程序中测试相同的内容，并比较映射体验和查询+性能。
目前，性能可能不是问题，但它可能是您未来必须优化的内容，EF将为您提供更少的功能。如果要提高EF解决方案的性能，通常会恢复到本机SQL和存储过程。你认为它有更好的编写查询经验吗？
答案 1 :(得分：6)
我不得不同意@Ladislav，EF和LINQ很好，它与NHibernate LINQ相比很有用，但是SQL EF生成有时非常糟糕且性能不是非常高并且您将被迫将复杂查询重新编码为视图和SP等等Nhibernate也可以陷入这个陷阱，但是有很多不同的选择是有益的，因为你可以选择最适合你的需求。
我想你正在考虑平衡以下几点： -
有点从一个ORM跳到另一个ORM就像从煎锅跳到火里。两个都有他们的甜点都会烧伤你的手指！
答案 2 :(得分：2)
我个人也遇到过Nhibernate的linq提供程序的问题。
但是，我选择坚持NHibernate，因为它具有“适当的”SQL生成，整体性能和可扩展性。
后者允许您使用您选择的二级缓存（例如MemcacheD）来缓解您的RDBMS。它将对象保留在内存中（在MemcacheD服务器上）仅在需要时从/向RDBMS提取/提交它们。也适用于编译的SQL查询。
答案 3 :(得分：1)
说实话，听起来你已经下定决心了。我不确定你在这里问的是什么。如果您有兴趣坚持使用NHibernate，您应该就您遇到的问题提出具体问题。
在我看来，如果您的团队更熟悉EF，那么您应该切换。如果他们不是，那么我不确定你是否会知道EF是否会解决你的所有问题，除非你实际勾勒出你遇到的具体问题。
答案 4 :(得分：0)
你试过Fluent NHibernate吗？ http://fluentnhibernate.org/。您可以使用LINQ。我在一个项目中使用它并且效果很好。