用LINQ to SQL或LINQ to EF替换NHibernate

Question

我们有一个很棒的项目使用NHibernate作为ORM。 我们想迁移到L2S或L2EF。 我们可以做NHibernate做的所有事情吗？

您是否建议我们从事这项工作？ 这项工作的优缺点是什么？ 这两个ORM具有共同的功能吗？

注意：我们的项目是用C＃编写的。

Answer 1

您是否有令人信服的理由来更改您的ORM？ 我会争辩说不要更改任何东西，因为您有一个现有的应用程序，该应用程序使用良好的持久性框架（受良好支持）可以很好地运行。

是的，您将可以使用NHibernate在实体框架上进行任何当前的操作（尽管不太确定LINQ to SQL），但不要为了框架而切换。 这就像在购买轮胎一周后就更换汽车上的轮胎-拥有崭新的轮胎可能会令人兴奋，但总之，它们只是轮胎。 您现在拥有的轮胎就很好了-也许在您为该项目分配的时间中，应用程序的其他领域会更好地受益吗？

Answer 2

除非你有一个很好的理由去改变你的ORM，这将是极大痛苦比它的价值。 更改ORM与交换数据库提供程序一样重要。

NHibernate中将具有其他ORM工具中不存在的功能（立即想到的组件），因此您必须找到解决方法或重新设计类或表结构以补偿所做的更改。

你应该做这项工作吗？ 我不建议。

Answer 3

如果您要切换，我强烈建议您不要将linq转换为sql，因为将来还不清楚 。 至于NHibernate和linq与实体之间的功能差异，Ayende Rahien有一些有关差异的博客文章。

1. nhibernate与实体框架4.0
2. 应对ef更好
3. ef 4.0可以做什么，nhibernate无法做到

仅供参考：Ayende是NHibernate团队的重要成员。

关于第二个问题。 在不知道NHibrinate如何使您失望的情况下，很难提出这项工作。 根据产品的状态和尺寸，我很难推荐没有充分考虑的原因就更改诸如ORM之类的应用程序的整体部分。

无论如何，NHibrinate是一种非常坚固的产品，并且在.net开源社区中拥有悠久的记录。 另一方面，Microsoft具有引入数据访问/ ORM解决方案并迅速放弃它们的历史。

Answer 4

LINQ到SQL 不支持任何地方接近整个功能集的NHibernate的。 我使用Linq到SQL并认为它很棒，但是它打算用作对数据库的直接1：1映射。 与NHibernate相比，它不是真正的ORM，而是数据访问解决方案。 除其他外，它丢失了：

• 组件属性；
• 多对多映射；
• 自动映射（尽管设计器工具主要弥补了这种缺陷）；
• 多平台支持（Linq to SQL仅真正支持SQL Server和SQL CE）
• 将多个表映射到一个类中

实体框架4就其功能集而言，它与NHibernate非常接近，您应该能够执行NHibernate目前能够执行的大部分工作。 但是我全心全意地同意其他建议，不要为了娱乐而更改您的ORM。 实际的语义非常不同，您最终将经历许多痛苦和错误修正周期。

Answer 5

您要迁移的原因是什么？ 现有解决方案不起作用吗？ 这是性能问题吗？ 我建议您花一点时间来确保您了解问题所在，性能或其他方面，并集中精力解决这些问题。 通过在数据库上使用正确的索引并使用NHibernate功能（例如批处理），您可能会发现无需重写即可解决问题。

另外，将LinqToNHibernate作为第一步。 Linq语法将与最终使用的语法相同。 那就是Linq的美丽。

Answer 6

NHibernate允许您在不始终调用DAL的情况下实现逻辑（“ 持久性无知 ”）。 这是可能的，因为NH比较内存中的实例并自动检测更改。

它具有出色的性能功能（例如，缓存，查询批处理，插入/更新批处理，延迟加载）。

以正确的方式使用NHibernate时，您编写应用程序就像没有任何持久性一样（可以说是80％），并且仍然可以获得高性能。 由于Linq to Sql或EF不提供此功能（AFAIK），因此我无法想象如何将大型应用程序迁移到该功能。 您的代码将需要一直调用DAL，而当前不需要。