|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-25
peterwei我不是说你的观点有问题，感觉就是太学院派了，我把我的观点标红了，我们应该关注业务设计，其实很多时候所谓的po一样可以分布式，hibernate的延迟加载，我一直不用的，因为dto只是实现业务的手段，这东西因为其运行时特性，故在业务设计中往往会带来不可预知的问题。
peterwei 写道
skzr.org 写道
我做企业应用的，以前也听某某、某某谈论dto、vo、po甚至其他oo。
yangyiqian 写道
首先我想说“存在就是真理”，DTO、PO绝对不是一个范畴的概念，DTO!=PO，所以也就谈不上谁代替谁的概念。当然了，你非要说老板就不能做员工的话吗？当然可以，不过这是做事的规矩吗？！
一、DTO与PO的不对称关系决定了二者不能互相代替 DTO与PO存在在映射关系，可能是多对一，也可能是一对多，最特殊的关系就是上面大家说的这种情况“一对一”。也就是在“一对一”的情况下可以实现DTO与PO的混用，而其他情况下，如果混用都需要PO进行冗余设计，考虑这些冗余设计会比直接的、简单的造一个新的DTO出现要耗费更多的脑细胞，同时这个东西又不利于后期维护，可以说“牵一发，动从上到下”。 二、性能上决定了PO代替DTO是个蹩脚的设计 PO是与数据库直接交互的对象，比如我要在页面上显示数据库中的数据，如果用PO来实现那么这个PO就得一直保持与数据库的连接，直到数据显示到页面上来。这样如果在service层有复杂运算的话，那么数据库方面的延时是非常可观的，而如果转换成DTO之后，数据库连接就可以尽快释放。所以从性能上来说应该使用DTO－－当然对于性能不是很苛刻的情况下不用DTO也行 －－不过，熟练的程序员应该养成按统一的方式做项目的习惯，我觉得这样会更高效。
最佳实践： 软件是发展的，我只认设计中的bean，如果bean要持久化就有po的职责了，一切都只是手段而已 难道是ORM把我们绑架了！太在意po和dto这样的概念了，设计才是根本，满足设计的bean才是核心。 就正如时刻要记住的技术是为了实现业务需求而用，很多人反过来用了，为了技术而技术，被技术忽悠。最简单、是人就可以看懂的实现才是好实现
我也说了，大多数的企业应用，是可以po从view-dao透传所有层的。但是一些特定场景，特别是分布式环境，异构环境，DTO模式还是很有必要存在的。PO和DTO的概念还是很有必要理清的。很多东西，由于个人的一些经验问题，接触得不多，往往很难一眼看清本质。特别是底层的人员，有时候会看不清楚一个设计为什么这样。所以我觉得讲讲，扫下盲是有必要的，特别是对团队内部的人来说。而不能什么都不让他们知道，只是强制执行。
|
| 返回顶楼 | |
|
发表时间：2011-04-25
有时需要传输像json，xml这样的数据类型到页面，这个时候用pojo转换明显不合适
（比如用hibernate时pojo转换json就会报错，某些日期格式需要做特殊处理等）我通常会创造一个中间对象（vo，dto）来负责传输或者转换。这样的转换肯定是有消耗的，不过如果不是特别注重性能的情况下，这种消耗是可以忽略，一切为了开发简单，层次清晰 |
| 返回顶楼 | |
|
发表时间：2011-04-25
peterwei 写道 分离的北极熊 写道 互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……
愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。 笑而不语~~ |
| 返回顶楼 | |
|
发表时间：2011-04-25
我觉得一个系统一个模块是否有必要写一个VO得看具体的情况吧。对于一个VO可能包含多个PO的情况那肯定需要VO，如果你的VO和PO一模一样，你还要弄个转化，这不是蛋疼没事干啊？难道是为了系统统一这么做，或者所谓的以后方便扩展？
|
| 返回顶楼 | |
|
发表时间：2011-04-25
peterwei 写道 分离的北极熊 写道 互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……
愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。 说别人悲惨，或者你是大牛不屑于别人的讨论，说出你的观点。让后来人也继续学习进步！ |
| 返回顶楼 | |
|
发表时间：2011-04-25
从另一篇帖子得知楼主是搞互联网的。。。。
把这个了链接发给LZ 仔细看看吧 http://gettingreal.37signals.com/GR_chn.php |
| 返回顶楼 | |
|
发表时间：2011-04-25
最后修改：2011-04-25
skzr.org 写道
peterwei我不是说你的观点有问题，感觉就是太学院派了，我把我的观点标红了，我们应该关注业务设计，其实很多时候所谓的po一样可以分布式，hibernate的延迟加载，我一直不用的，因为dto只是实现业务的手段，这东西因为其运行时特性，故在业务设计中往往会带来不可预知的问题。
peterwei 写道
skzr.org 写道
我做企业应用的，以前也听某某、某某谈论dto、vo、po甚至其他oo。
yangyiqian 写道
首先我想说“存在就是真理”，DTO、PO绝对不是一个范畴的概念，DTO!=PO，所以也就谈不上谁代替谁的概念。当然了，你非要说老板就不能做员工的话吗？当然可以，不过这是做事的规矩吗？！
一、DTO与PO的不对称关系决定了二者不能互相代替 DTO与PO存在在映射关系，可能是多对一，也可能是一对多，最特殊的关系就是上面大家说的这种情况“一对一”。也就是在“一对一”的情况下可以实现DTO与PO的混用，而其他情况下，如果混用都需要PO进行冗余设计，考虑这些冗余设计会比直接的、简单的造一个新的DTO出现要耗费更多的脑细胞，同时这个东西又不利于后期维护，可以说“牵一发，动从上到下”。 二、性能上决定了PO代替DTO是个蹩脚的设计 PO是与数据库直接交互的对象，比如我要在页面上显示数据库中的数据，如果用PO来实现那么这个PO就得一直保持与数据库的连接，直到数据显示到页面上来。这样如果在service层有复杂运算的话，那么数据库方面的延时是非常可观的，而如果转换成DTO之后，数据库连接就可以尽快释放。所以从性能上来说应该使用DTO－－当然对于性能不是很苛刻的情况下不用DTO也行 －－不过，熟练的程序员应该养成按统一的方式做项目的习惯，我觉得这样会更高效。
最佳实践： 软件是发展的，我只认设计中的bean，如果bean要持久化就有po的职责了，一切都只是手段而已 难道是ORM把我们绑架了！太在意po和dto这样的概念了，设计才是根本，满足设计的bean才是核心。 就正如时刻要记住的技术是为了实现业务需求而用，很多人反过来用了，为了技术而技术，被技术忽悠。最简单、是人就可以看懂的实现才是好实现
我也说了，大多数的企业应用，是可以po从view-dao透传所有层的。但是一些特定场景，特别是分布式环境，异构环境，DTO模式还是很有必要存在的。PO和DTO的概念还是很有必要理清的。很多东西，由于个人的一些经验问题，接触得不多，往往很难一眼看清本质。特别是底层的人员，有时候会看不清楚一个设计为什么这样。所以我觉得讲讲，扫下盲是有必要的，特别是对团队内部的人来说。而不能什么都不让他们知道，只是强制执行。
我们是只关注业务设计呀。正因为有那样的业务场景，所以才有我说的那两个特别的项目用dto的。而大多数都用po透传。在有remote的业务场景里，dto还是必需的。所有的技术都是实现业务的手段，这点是没有什么疑问的。就看哪种技术适合哪种场景，还有我们在进行架构设计时的取舍。如dto模式可以利于以后的扩展性，但如果不用也是行的，等以后再重构好了。dto并不会在开发中带来不可预知的问题。我认为唯一的缺点就是，大量的dto-po,po-dto的转换,增大了工作量而已。 |
| 返回顶楼 | |
|
发表时间：2011-04-25
Cindy_Lee 写道 有时需要传输像json，xml这样的数据类型到页面，这个时候用pojo转换明显不合适
（比如用hibernate时pojo转换json就会报错，某些日期格式需要做特殊处理等）我通常会创造一个中间对象（vo，dto）来负责传输或者转换。这样的转换肯定是有消耗的，不过如果不是特别注重性能的情况下，这种消耗是可以忽略，一切为了开发简单，层次清晰 这种消耗，基本可以忽略不计。 |
| 返回顶楼 | |
|
发表时间：2011-04-25
accphc 写道 peterwei 写道 分离的北极熊 写道 互联网的时代了，做web应用的还在纠结于VO/PO/DTO/的概念，真悲催……
愿听大牛高见。不管什么年代了，总是会有后人加入到开发行业来，人都是一下子懂所有的事情的吗？悲催什么，你连自已的观点都没有。 说别人悲惨，或者你是大牛不屑于别人的讨论，说出你的观点。让后来人也继续学习进步！ 说是大牛，只是客气。他不说观点，我就是bs了。 |
| 返回顶楼 | |
|
发表时间：2011-04-25
|
| 返回顶楼 | |
