17,740
社区成员
发帖
与我相关
我的任务
分享召唤NHibernate和Linq to SQL高手
有没有哪位朋友用过这两种方法，比较一下pros&cons. 我们开发小组前几个项目是用的Linq to SQL， 一致认为对于快速开发，小型项目，Linq to SQL是绝对的好选择。最近小组又在一起开发一个大一点的项目，试着使用NHibernate, 到目前为止，我们解决了遇到的问题， NHibernate看起来没有问题。mapping的时候，我们对HHibernate的配置不是很熟，但是还是解决了。如果用Linq to SQL，更简单， 只要搞一个DBML，直接把表拖进来就能用了。请大家对这两种方法的优缺点评论一下。还有我们小组的老大写了一个blog也是关于这个，大家可以去看，提点评论。欢迎技术讨论！非常感谢！
http://derans.blogspot.com/2009/07/linq-to-sql-vs-nhibernate.html
http://derans.blogspot.com/2009/07/linq-to-sql-vs-nhibernate.html
...全文
请发表友善的回复…
发表回复
shenqi520 2011-06-13
- 打赏
- 举报
说的好，说到我心头，。了
du2003 2009-08-22
- 打赏
- 举报
[Quote=引用 20 楼 acqy 的回复:]
引用 18 楼 sozdream 的回复:
如果LZ用hibernate的话, 推荐使用Castle的Active Record,
基于hibernate, 但改进很多.
对于中小型系统，我推荐使用castle active record。我曾经有过一个基于castle active record的领域驱动设计实践，源代码和介绍信息：【StoreDDD】。
我
[/Quote]
说得不错,很受益!顶一下!
其实 xpo 也可以从 实体模型 到 数据库 的.
另外, 现在 NHibernate 有了 新的 发展 方向:
http://sourceforge.net/projects/nhibernate/files/
引用 18 楼 sozdream 的回复:
如果LZ用hibernate的话, 推荐使用Castle的Active Record,
基于hibernate, 但改进很多.
对于中小型系统，我推荐使用castle active record。我曾经有过一个基于castle active record的领域驱动设计实践，源代码和介绍信息：【StoreDDD】。
我
[/Quote]
说得不错,很受益!顶一下!
其实 xpo 也可以从 实体模型 到 数据库 的.
另外, 现在 NHibernate 有了 新的 发展 方向:
http://sourceforge.net/projects/nhibernate/files/
acqy 2009-07-29
- 打赏
- 举报
[Quote=引用 18 楼 sozdream 的回复:]
如果LZ用hibernate的话, 推荐使用Castle的Active Record,
基于hibernate, 但改进很多.
[/Quote]
对于中小型系统，我推荐使用castle active record。我曾经有过一个基于castle active record的领域驱动设计实践，源代码和介绍信息：【StoreDDD】。
我曾经在领域驱动设计的官方论坛上介绍了active record的引入，但最终被人痛批一顿，此时我才恍然大悟，active record和domain model是两个完全不同的模式。
Fowler在其PoEAA中有介绍三种模式，transaction script, active record和domain model。简单地说，这三种模式在“分层解耦的能力”上是逐步递增的。不能说transaction script和active record不好，而是在某些应用场合，前两者比domain model更合适。
从应用的角度去考虑，我们会发现，在.net中，只要定义实体的地方，就得做好两件事情，第一，对实体类及其属性成员添加相应的特性，而这些特性就是数据库相关的；第二（可选），实体从ActiveRecord<T>继承。针对第二件事情我持保留意见，因为你还可以使用遗留的ActiveRecordMediator去做CRUD，但对于第一件事情，领域驱动设计是无法接受的：它在领域模型中的实体上参杂了太多本不属于领域模型的内容。这一点，也正是LINQ to SQL的软肋。
我始终坚持，模式没有对与错，只有合适与不合适。如果楼主觉得LINQ to SQL能够完全满足自己的需求，那我推荐LINQ to SQL，毕竟简单明了。
如果LZ用hibernate的话, 推荐使用Castle的Active Record,
基于hibernate, 但改进很多.
[/Quote]
对于中小型系统，我推荐使用castle active record。我曾经有过一个基于castle active record的领域驱动设计实践，源代码和介绍信息：【StoreDDD】。
我曾经在领域驱动设计的官方论坛上介绍了active record的引入，但最终被人痛批一顿，此时我才恍然大悟，active record和domain model是两个完全不同的模式。
Fowler在其PoEAA中有介绍三种模式，transaction script, active record和domain model。简单地说，这三种模式在“分层解耦的能力”上是逐步递增的。不能说transaction script和active record不好，而是在某些应用场合，前两者比domain model更合适。
从应用的角度去考虑，我们会发现，在.net中，只要定义实体的地方，就得做好两件事情，第一，对实体类及其属性成员添加相应的特性，而这些特性就是数据库相关的；第二（可选），实体从ActiveRecord<T>继承。针对第二件事情我持保留意见，因为你还可以使用遗留的ActiveRecordMediator去做CRUD，但对于第一件事情，领域驱动设计是无法接受的：它在领域模型中的实体上参杂了太多本不属于领域模型的内容。这一点，也正是LINQ to SQL的软肋。
我始终坚持，模式没有对与错，只有合适与不合适。如果楼主觉得LINQ to SQL能够完全满足自己的需求，那我推荐LINQ to SQL，毕竟简单明了。
yitianlige 2009-07-29
- 打赏
- 举报
up
龙翔飞雪 2009-07-28
- 打赏
- 举报
如果LZ用hibernate的话, 推荐使用Castle的Active Record,
基于hibernate, 但改进很多.
基于hibernate, 但改进很多.
caotoulei 2009-07-28
- 打赏
- 举报
[Quote=引用 14 楼 acqy 的回复:]
真正的领域驱动设计，你是不会去考虑你的系统是否有数据库的。Evans的DDD中很少提及数据库这类概念，而更多的是在讲仓储。
LINQ to SQL还有个致命伤，就是对值对象的支持。Jimmy在InfoQ中讨论过这个问题，由于LINQ to SQL不像NHibernate那样能够很好地支持值对象，因此，他觉得自己很难适应LINQ to SQL的做法。
“我们开发的时候是先设计Model， 再对这些对象写Repository，然后才是拖数据库的表，再mapping,再写filter等。”
先设计Model，再写Repository，从分析流程上看是没错，但“拖数据库的表”就感觉无法让人接受。数据库表是从哪里来？通过设计时模型的描述，手动地在SQL Server或者Oracle上建立的么？那如果设计时模型改了怎么办？是不是也要修改数据库中的表？当然visual studio会使用refactor来同步其本身的Model，但是由于数据库的更改而去改变Model，这本身就搞反了。
从NHibernate对SchemaExport和SchemaUpdate的支持能够看出，NHibernate是有能力通过模型来同步持久化机制（也就是目前谈论的最多的“数据库”）的，如果你的模型改变了，SchemaUpdate可以以增量方式同步你的持久化机制，那么此时你的数据库中的表有可能一团糟，比如某些表因为模型对象的删除而不再使用，而某些字段又因为模型对象属性的添加而添加。但这都没有关系，NHibernate会帮你处理这些事情，你只需要关注你的模型就行了，数据库到底成什么样，你根本不需要去考虑。
相关文献你可以参阅：
面向数据库与面向对象的一些理解
数据库时代的终结
数据库已死
[/Quote]
非常感谢，这就是我想要知道的。因为刚接触HNibernate一个星期，只知道简单的mapping，你提到的的“通过模型同步持久化机制”还没有掌握，继续学习。我要show给我经理看你的留言和Jimmy的InfoQ的文章。非常感谢！
真正的领域驱动设计，你是不会去考虑你的系统是否有数据库的。Evans的DDD中很少提及数据库这类概念，而更多的是在讲仓储。
LINQ to SQL还有个致命伤，就是对值对象的支持。Jimmy在InfoQ中讨论过这个问题，由于LINQ to SQL不像NHibernate那样能够很好地支持值对象，因此，他觉得自己很难适应LINQ to SQL的做法。
“我们开发的时候是先设计Model， 再对这些对象写Repository，然后才是拖数据库的表，再mapping,再写filter等。”
先设计Model，再写Repository，从分析流程上看是没错，但“拖数据库的表”就感觉无法让人接受。数据库表是从哪里来？通过设计时模型的描述，手动地在SQL Server或者Oracle上建立的么？那如果设计时模型改了怎么办？是不是也要修改数据库中的表？当然visual studio会使用refactor来同步其本身的Model，但是由于数据库的更改而去改变Model，这本身就搞反了。
从NHibernate对SchemaExport和SchemaUpdate的支持能够看出，NHibernate是有能力通过模型来同步持久化机制（也就是目前谈论的最多的“数据库”）的，如果你的模型改变了，SchemaUpdate可以以增量方式同步你的持久化机制，那么此时你的数据库中的表有可能一团糟，比如某些表因为模型对象的删除而不再使用，而某些字段又因为模型对象属性的添加而添加。但这都没有关系，NHibernate会帮你处理这些事情，你只需要关注你的模型就行了，数据库到底成什么样，你根本不需要去考虑。
相关文献你可以参阅：
面向数据库与面向对象的一些理解
数据库时代的终结
数据库已死
[/Quote]
非常感谢，这就是我想要知道的。因为刚接触HNibernate一个星期，只知道简单的mapping，你提到的的“通过模型同步持久化机制”还没有掌握，继续学习。我要show给我经理看你的留言和Jimmy的InfoQ的文章。非常感谢！
aofong19871029 2009-07-28
- 打赏
- 举报
用entity framework 用实体模型来做 既有linq to sql的简单 能站对实体模型的操作来完成数据库的操作
acqy 2009-07-28
- 打赏
- 举报
真正的领域驱动设计，你是不会去考虑你的系统是否有数据库的。Evans的DDD中很少提及数据库这类概念，而更多的是在讲仓储。
LINQ to SQL还有个致命伤，就是对值对象的支持。Jimmy在InfoQ中讨论过这个问题，由于LINQ to SQL不像NHibernate那样能够很好地支持值对象，因此，他觉得自己很难适应LINQ to SQL的做法。
“我们开发的时候是先设计Model， 再对这些对象写Repository，然后才是拖数据库的表，再mapping,再写filter等。”
先设计Model，再写Repository，从分析流程上看是没错，但“拖数据库的表”就感觉无法让人接受。数据库表是从哪里来？通过设计时模型的描述，手动地在SQL Server或者Oracle上建立的么？那如果设计时模型改了怎么办？是不是也要修改数据库中的表？当然visual studio会使用refactor来同步其本身的Model，但是由于数据库的更改而去改变Model，这本身就搞反了。
从NHibernate对SchemaExport和SchemaUpdate的支持能够看出，NHibernate是有能力通过模型来同步持久化机制（也就是目前谈论的最多的“数据库”）的，如果你的模型改变了，SchemaUpdate可以以增量方式同步你的持久化机制，那么此时你的数据库中的表有可能一团糟，比如某些表因为模型对象的删除而不再使用，而某些字段又因为模型对象属性的添加而添加。但这都没有关系，NHibernate会帮你处理这些事情，你只需要关注你的模型就行了，数据库到底成什么样，你根本不需要去考虑。
相关文献你可以参阅：
面向数据库与面向对象的一些理解
数据库时代的终结
数据库已死
LINQ to SQL还有个致命伤，就是对值对象的支持。Jimmy在InfoQ中讨论过这个问题，由于LINQ to SQL不像NHibernate那样能够很好地支持值对象，因此，他觉得自己很难适应LINQ to SQL的做法。
“我们开发的时候是先设计Model， 再对这些对象写Repository，然后才是拖数据库的表，再mapping,再写filter等。”
先设计Model，再写Repository，从分析流程上看是没错，但“拖数据库的表”就感觉无法让人接受。数据库表是从哪里来？通过设计时模型的描述，手动地在SQL Server或者Oracle上建立的么？那如果设计时模型改了怎么办？是不是也要修改数据库中的表？当然visual studio会使用refactor来同步其本身的Model，但是由于数据库的更改而去改变Model，这本身就搞反了。
从NHibernate对SchemaExport和SchemaUpdate的支持能够看出，NHibernate是有能力通过模型来同步持久化机制（也就是目前谈论的最多的“数据库”）的，如果你的模型改变了，SchemaUpdate可以以增量方式同步你的持久化机制，那么此时你的数据库中的表有可能一团糟，比如某些表因为模型对象的删除而不再使用，而某些字段又因为模型对象属性的添加而添加。但这都没有关系，NHibernate会帮你处理这些事情，你只需要关注你的模型就行了，数据库到底成什么样，你根本不需要去考虑。
相关文献你可以参阅：
面向数据库与面向对象的一些理解
数据库时代的终结
数据库已死
HRTStation 2009-07-28
- 打赏
- 举报
Nhibernate只是数据访问层，在很大程度上受存储结构的限制，其实存储结构与域模型应区分开设计
acqy 2009-07-27
- 打赏
- 举报
优缺点：
LINQ to SQL简单，对于从数据库设计出发的应用，是一个不错的选择，但只能适用于小型软件系统，因为面向数据库的设计会麻痹人的“面向对象”神经，对于业务复杂的大型系统，面向数据库的设计会使人迷失方向。
NHibernate复杂，配置和事务处理都需要经过深思熟虑，但它的引入会将领域实体与基础结构层实现解耦，是符合领域驱动设计思想的。
LINQ to SQL简单，对于从数据库设计出发的应用，是一个不错的选择，但只能适用于小型软件系统，因为面向数据库的设计会麻痹人的“面向对象”神经，对于业务复杂的大型系统，面向数据库的设计会使人迷失方向。
NHibernate复杂，配置和事务处理都需要经过深思熟虑，但它的引入会将领域实体与基础结构层实现解耦，是符合领域驱动设计思想的。
acqy 2009-07-27
- 打赏
- 举报
关键看你的应用程序的需求，如果规模不大，而且LINQ to SQL能够解决你的问题，何乐而不为？
个人偏向于NHibernate，因为从领域驱动设计的方向考虑，LINQ to SQL已经本末倒置了：先有数据库表的结构再有领域实体，这是面向数据库的设计，而不是领域驱动设计。
个人偏向于NHibernate，因为从领域驱动设计的方向考虑，LINQ to SQL已经本末倒置了：先有数据库表的结构再有领域实体，这是面向数据库的设计，而不是领域驱动设计。
caotoulei 2009-07-27
- 打赏
- 举报
[Quote=引用 11 楼 acqy 的回复:]
优缺点：
LINQ to SQL简单，对于从数据库设计出发的应用，是一个不错的选择，但只能适用于小型软件系统，因为面向数据库的设计会麻痹人的“面向对象”神经，对于业务复杂的大型系统，面向数据库的设计会使人迷失方向。
NHibernate复杂，配置和事务处理都需要经过深思熟虑，但它的引入会将领域实体与基础结构层实现解耦，是符合领域驱动设计思想的。
[/Quote]
谢谢这位兄弟的回帖“它的引入会将领域实体与基础结构层实现解耦”说的非常有道理。但是对于 LINQ to SQL, 为什么说它是“面向数据库”的呢？我不是很理解。我们开发的时候是先设计Model， 再对这些对象写Repository，然后才是拖数据库的表，再mapping,再写filter等。是不是如果mapping的时候过于复杂，比如超过4，5个表需要join，这样就会不自觉的考虑到数据库？因为我的上一个项目没有复杂到那个地步，所以并没有采取先数据库结构在领域的设计顺序。
另外我的msn是caotoulei@hotmail.com,可以加我指导交流吗？谢谢。
优缺点：
LINQ to SQL简单，对于从数据库设计出发的应用，是一个不错的选择，但只能适用于小型软件系统，因为面向数据库的设计会麻痹人的“面向对象”神经，对于业务复杂的大型系统，面向数据库的设计会使人迷失方向。
NHibernate复杂，配置和事务处理都需要经过深思熟虑，但它的引入会将领域实体与基础结构层实现解耦，是符合领域驱动设计思想的。
[/Quote]
谢谢这位兄弟的回帖“它的引入会将领域实体与基础结构层实现解耦”说的非常有道理。但是对于 LINQ to SQL, 为什么说它是“面向数据库”的呢？我不是很理解。我们开发的时候是先设计Model， 再对这些对象写Repository，然后才是拖数据库的表，再mapping,再写filter等。是不是如果mapping的时候过于复杂，比如超过4，5个表需要join，这样就会不自觉的考虑到数据库？因为我的上一个项目没有复杂到那个地步，所以并没有采取先数据库结构在领域的设计顺序。
另外我的msn是caotoulei@hotmail.com,可以加我指导交流吗？谢谢。
chen_ya_ping 2009-07-26
- 打赏
- 举报
正在学习LINQ
IHandler 2009-07-26
- 打赏
- 举报
用NHibernate
grzx2210 2009-07-26
- 打赏
- 举报
顶
caotoulei 2009-07-25
- 打赏
- 举报
谢谢大家支持，我准备周一写一个 performance test看看到底差多少，然后好汇报呵呵。
十八道胡同 2009-07-23
- 打赏
- 举报
帮顶，能有效解决问题和能简单维护的都可以
LQknife 2009-07-23
- 打赏
- 举报
帮顶
caotoulei 2009-07-23
- 打赏
- 举报
自己来顶一下。
wenblue7 2009-07-23
- 打赏
- 举报
看看
顶顶
顶顶
加载更多回复（1）
