用LINQ to SQL或LINQ to EF替换NHibernate

Linq到SQL确实如此 不

• 部件特性;
• 将多个表映射到单个类

EntityFramework4在特性集方面与NHibernate非常接近,您应该能够完成目前在NHibernate中能够完成的大部分工作。但我完全同意其他人的建议,不要仅仅为了好玩而改变你的ORM;实际的语义是非常不同的,您最终将经历一个 许多

你有没有令人信服的理由改变你的ORM?我认为不要改变任何东西,因为您有一个现有的应用程序,它使用一个良好的持久性框架,并得到很好的支持。

除非你有一个很好的理由改变你的ORM,否则这将是 极大地 更多的痛苦。更改ORM与交换数据库提供程序一样重要。

NHibernate中会有其他ORM工具中没有的特性(组件会立即浮现在脑海中),因此您必须找到解决方法或重新设计类或表结构来补偿更改。

very unclear . 至于NHibernate和linq to entities之间的功能差异,Ayende Rahien在博客上发表了一些关于差异的文章。

1. nhibernate vs. entity framework 4.0
2. responding to how ef is better
3. what can ef 4.0 do that nhibernate can't

关于你的第二个问题。如果你不知道NHibrinate是如何让你失望的,你就很难提议做这项工作。根据产品的状态和大小,我很难建议您在没有经过深思熟虑的原因的情况下更改应用程序的一个完整部分,比如ORM。

你想移民的原因是什么?现有的解决方案不起作用吗?是性能问题吗?我建议您花一点时间确保您了解问题是什么、性能或其他方面,并将重点放在这些方面。在数据库上使用正确的索引并使用NHibernate特性(如批处理)后,您可能会发现问题不需要重写就可以解决。

NHibernate允许您实现您的逻辑,而无需一直调用DAL(“ 坚持无知 "). 这是可能的,因为NH比较内存中的实例并自动检测更改。

它有很大的优势 演出 特性(例如缓存、查询批处理、插入/更新批处理、延迟加载)。

当以正确的方式使用NHibernate时,您编写应用程序时就好像没有任何持久性(比如说:到80%)一样,并且仍然可以获得高性能。由于linqtosql或EF不提供此功能(AFAIK),我无法想象如何将大型应用程序迁移到该功能。您的代码将需要一直调用DAL,而目前它没有。