我有一个使用 NHibernate 编写的旧的过时应用程序。现在我想重写它，包括新功能和模型的重大变化。
使用 Linq to SQL 而不是 NHibernate 的主要缺点是什么？
使用 LINQ to SQL 可能会出现哪些问题，将 DataContext 设置为类似单例的方式会导致性能不佳吗？
最佳答案
来自 "The false myth of encapsulating data access in the DAL" :
"I would like to design a system/application using NHibernate. But I also want to so flexible that in future ,if I unplug the NHibernate and use ADO.NET Entity framework or other framework then my application should not crash."
总之，我完全反对 甚至尝试做那样的事情。
它基于有缺陷的假设
这背后的很多驱动力是 基于内置的历史驱动器 数据访问层的时间 使用其直接访问数据库 自己的方言，导致需要 在中创建这样的封装 为了支持多个数据库。
这个驱动器的问题在于它 不再是一个因素，所有现代 OR/Ms 可以处理多个数据库 有效地。此外，现代 OR/M 是 不再只是执行某些操作的方法 SQL并得到一个结果，这是 旧式 DAL 是如何编写的。一个 OR/M 承担更多 责任，例如 更改跟踪缓存管理， 从确保乐观并发 管理与最佳沟通 数据库。
这些功能非常重要。不是 仅此而已，但它们是不同的 在每个 OR/M 之间。
它不起作用，你会发现为时已晚
主要问题是无论怎样 你努力尝试，会有 微妙和不那么微妙的区别 在不同的 OR/M 之间，那些变化 会极大地影响您的构建方式 你的申请。
那么您如何在 OR/M 之间移动？
有些人想要从一种数据访问技术转移到另一种数据访问技术是有原因的。我参与了多项此类工作，我们在每个案例中使用的方法都是移植，而不是尝试放弃新的 IDataAccess 实现。
关于c# - 在 Linq to SQL 中重写 NHibernate 应用程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3840460/