nhibernate - 选择 ORM 时，LINQ to SQL 或 LINQ to Entities 是否比 NHibernate 更好？

Question

我发现使用 NHibernate 甚至 Castle 比使用 Linq to Entities 或 linq to SQL 可以做更多的事情。

我疯了吗？

Answer 1

不，你没有疯。nHibernate 是一个完整的 OR 映射器，Linq to SQL 和 Linq to Entities 并没有实现您对 OR 映射器所期望的所有内容，而是针对稍微不同的开发人员群体。

但是不要让它让你离开 linq。Linq 仍然是一个不错的主意.. 尝试使用 Linq 到 nHibernate :-)

Answer 2

NHibernate、Castle 等的最大缺点是它们并不完全是轻量级的（尤其是 NHibernate。）

Linq to SQL 适用于轻量级、有限使用的 ORM。

Answer 3

我使用过 NHibernate 和 LINQ to SQL。从我的角度来看，这取决于项目，如果我需要快速的东西，我会选择 L2S，创建 dbml 映射并开始使用它非常简单。如果我正在开发更高级的企业解决方案，我会选择久经考验且值得信赖的 ORM - NHibernate，我发现日志记录和事务功能易于使用。

LINQ to SQL 的学习曲线相对较短，NHibernate 的学习曲线要​​陡峭得多。

LINQ to SQL 仅支持 SQL Server，因此如果您有一个 Oracle 数据库，那么您已经做出了决定 - NHibernate。

我建议查看http://www.summerofnhibernate.com/以获取有关学习 NHibernate 的优秀截屏视频。

Answer 4

要记住的一件事是，NHibernate 可以是一个绝对的配置猪 - 特别是因为它主要基于 XML 配置文件，因为它的根源是原始的 Hibernate。

Fluent NHibernate在某种程度上减轻了这种痛苦。

Linq 当然适合 .NET 工作的一般“方式”。

Answer 5

Blockquote Linq 当然符合 .NET 工作的一般“方式”

哎呀，这种情绪吓到我了。.net 中内置的 RAD 东西不是 dot net 的工作方式，它只是一个用于构建原型的工具集。.NET 允许我们执行完整的 DDD 应用程序，具有高水平的内聚、关注点分离，并允许我们编写解耦代码，尽管 ms 尝试将事物耦合起来。我强烈不同意.net 喜欢耦合，某些工具喜欢耦合，我将在这场战斗中包括 linq to sql。linq to sql 破坏了拥有单独域模型的想法。想到使用我的数据库模式作为底层模型对象，我感到畏缩。适当的 ORM 工具应该允许我们首先对我们的域进行建模，然后将我们的关系数据库链接到这些模型。不是相反。

Answer 6

我没有尝试过实体框架，但我肯定会推荐 NHibernate 而不是 Linq to SQL；我能给出的最大理由就是控制权。Linq to SQL 喜欢对所有内容进行更多控制，加载对象并维护有关对象的各种跟踪信息。如果您序列化/反序列化，跟踪信息可能会丢失，再次保存时可能会发生奇怪的事情。NHibernate 更像是一个存储库应该工作 - 您将任何您想要的对象交给它（当然，您已经将其配置为可以理解），并且无论您使用它做了什么，它都会将它放在数据库中。