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

我疯了吗？

解决方案

回答

不，你不疯。 nHibernate是一个完整的OR映射器，Linq to SQL和Linq to Entities无法实现OR映射器期望的所有功能，并且针对的开发人员群体略有不同。

但是不要让那让你失望。 Linq仍然是一个不错的主意。尝试使用Linq来nHibernate :-)

回答

NHibernate，Castle等的最大缺点是它们的重量并不轻(尤其是NHibernate)。

Linq to SQL对于轻量级，有限用途的ORM很有用。

回答

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

流利的NHibernate可以减轻痛苦。

Linq当然可以适应.NET的一般"方式"。

回答

我已经将NHibernate和LINQ都用于SQL。从我的角度来看，这取决于项目，如果我需要快速的操作，我会选择L2S，创建dbml映射并开始使用它是如此简单。如果我正在开发更高级的企业解决方案，那么我会去尝试久经考验且受信任的ORM NHibernate，我会发现日志和事务功能易于使用。

LINQ to SQL的学习曲线相对较短，NHibernate的学习曲线更为陡峭。

LINQ to SQL仅支持SQL Server，因此，如果我们有Oracle数据库，则已由NHibernate做出决定。

我建议我们访问http://www.summerofnhibernate.com/，以获得有关学习NHibernate的出色屏幕录像。

回答

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

回答

Blockquote Linq certainly though fits in with the general 'way' in which .NET works

kes，这种情绪使我感到恐惧。 .net中内置的RAD内容不是点网的工作原理，它只是用于建立原型的工具集。 .NET允许我们执行完整的DDD应用程序，具有较高的内聚力，关注点分离，并且尽管ms试图进行耦合，但仍可以编写解耦的代码。我非常不同意.net喜欢被耦合，证书工具也喜欢被耦合，我将把linq包含到sql中。 linq to sql破坏了使用单独的域模型的想法。我不禁想到将数据库架构用作基础模型对象。正确的ORM工具应允许我们首先为我们的域建模，然后将我们的关系数据库链接到这些模型。并非相反。