30 当选择ORM时,是LINQ to SQL还是LINQ to Entities优于NHibernate?

我发现我可以用NHibernate做更多,甚至比用Linq to Entities或Linq to SQL做得更多。

我是疯了吗?

请先 登录 后评论

6 个回答

Mendelt

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

但不要因此而放弃linq。Linq仍然是一个不错的主意。尝试Linq nHibernate:-)

请先 登录 后评论
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工具应该允许我们首先对域建模,然后将关系数据库链接到这些模型。而不是反过来。

请先 登录 后评论