不，你没疯。nHibernate是一个完整的OR映射器，Linq to SQL和Linq to Entities并没有实现你所期望的所有OR映射器，针对的是稍微不同的开发人员群体。
但不要因此而放弃linq。Linq仍然是一个不错的主意。尝试Linq nHibernate:-)
6 个回答
Mendelt
Ian P
NHibernate、Castle等的最大缺点是它们不是完全轻量级的(尤其是NHibernate)。
Linq to SQL非常适合轻量级、有限使用的ORM。
Kieran Benton
要记住的一件事是，NHibernate绝对是一头配置猪——尤其是它主要基于XML配置文件，因为它的根是最初的Hibernate。
流畅的NHibernate在某种程度上减少了这种痛苦。
Linq当然符合。net工作的一般“方式”。
rutger
我用过NHibernate和LINQ到SQL。在我看来，这取决于项目，如果我需要一些快速的东西，我会选择L2S，它是如此简单，创建dbml映射并开始使用它。如果我要开发一个更高级的企业解决方案，我会选择可靠的ORM - NHibernate，我发现它的日志记录和事务特性使用起来很简单。
从LINQ到SQL的学习曲线相对较短，而NHibernate的学习曲线则陡峭得多。
LINQ to SQL只支持SQL Server，所以如果你有一个Oracle数据库，那么决定已经做出- NHibernate。
我建议你去http://www.summerofnhibernate.com/看看关于学习NHibernate的优秀视频。
Chris Shaffer
我没有尝试过实体框架，但我肯定会推荐NHibernate而不是Linq到SQL;我能给出的最大原因就是控制。Linq to SQL喜欢对一切有更多的控制，加载对象和维护关于对象的各种跟踪信息。如果序列化/反序列化，跟踪信息可能会丢失，在再次保存它时可能会发生奇怪的事情。NHibernate更像是一个存储库——你给它任何你想要的对象(当然，你已经配置好让它理解)，然后它把它放在数据库中，不管你对它做了什么。
Community
Blockquote Linq当然符合。net工作的一般“方式”
哎呀，这种情绪吓到我了。.net内建的RAD东西并不是。net的工作方式，它只是一个建立原型的工具集。net允许我们做完整的DDD应用程序，具有高水平的内聚性，关注点分离，并允许我们编写解耦代码，尽管ms做了很多尝试。我强烈反对。net喜欢被耦合，某些工具喜欢被耦合，我将包括linq到sql。Linq to SQL破坏了拥有独立域模型的想法。一想到使用数据库模式作为底层模型对象，我就畏缩不前。适当的ORM工具应该允许我们首先对域建模，然后将关系数据库链接到这些模型。而不是反过来。