c# - 从 NHibernate 迁移到 Entity Framework 4.1？

Question

我知道问这个问题可能有点危险，但我真的需要一些意见。

我们已经有了我们的系统，它是一个网站(将成为流行的门户网站，我们使用 MVC3)，在我来这里之前，我的其他同事选择 NHibernate 作为他们的 OR Mapper 解决方案，他们开始编写条件查询等等..

现在团队更接近于 Linq 方法，所以我们尝试在内置的 Linq 提供程序中编写查询。问题是......它的适应性非常差 - 从字面上看，你不能编写非平凡的查询并且不会得到 不支持的异常...

我们认为这是最后可能的时刻，将我们的 OR 映射器更改为更基于 Linq 的东西，并且自从 EF4.1 获得了非常友好的代码优先选项后，我们决定这就是我们需要的。

我需要一些意见的问题值得花时间从 NHibernate 迁移到 EF4.1...该项目将至少持续一年的开发，因此我们有很多工作要做，并且我们希望以良好且不令人沮丧的方式做到这一点..

一些事实:

• 我们的项目中有大约 50 个实体
• 我们有大约 160 个用 Criteria API 编写的查询(全部包含在单元测试中)
• 我们需要复合、继承和多对多的支持
• 项目将是现在的两倍
• 我们对我们的数据库性能不满意
• 我们讨厌现在编写查询的方式!

所以.. 现在.. 迁移是好还是坏主意？ EF 会解决我们的问题吗？它会让我们开心还是那一步只会浪费我们的时间？

问候

Answer 1

请注意，您会将更好的 linq 支持换成更差的映射功能，有时甚至更差的性能(inheritance queries，no query or command batching，...)。现在回到黑板前再想一想。如果您现在不喜欢您的数据库性能，那么使用 EF 很难提高它。

我想改变技术有点晚了——它会付出高昂的代价。但是无论如何，如果您真的想这样做，为什么不进行概念验证，您可以使用一些非常复杂的映射功能和一些高级查询，然后首先尝试在 EF 代码中执行相同的操作？您可以在简单的控制台应用程序中测试相同的内容，并比较映射体验和查询 + 性能。

性能目前可能不是问题，但它可能是您将来真正需要优化的东西，EF 会为此提供更少的功能。如果您想提高 EF 解决方案的性能，您通常会恢复到 native SQL 和存储过程。您认为它在编写查询时会有更好的体验吗？