|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-26
pufan 写道 就问楼主一个问题：OO中的Object与layer之间有啥关系，这个啥关系都没有的道理如搞不清楚，扯那些po，dto，vo都是浮云，浮动在层上的云。
Object你又指的是什么？什么叫做和层没有关系？PO一般对应数据持久层的domain object，DTO(VO)对应大的封装过的domain object,一般用于特定场景，特别是服务层和界面(又以异构系统最常见)的接口数据。我们为了各层之间没有互相侵入性，隔离一些变化，所以有了分层解藕的概念,最终产生各层间传递对象的标准化。什么叫啥关系都没有的？你问就问得清晰些，我不想扯太多没用的。我认为我所说的还是很浅显的。不过你觉得是浮云，但我并不认为是这样的。了解不同场景下使用哪些东西，是很有必要的。不再多说了。 
|
| 返回顶楼 | |
|
发表时间：2011-04-26
Cindy_Lee 写道 star022 写道 VO DTO POJO，都只是数据的封装而已，
如果每层交互都要做对象转换，重复代码多， 除了增加研发和维护的人力成本，意义究竟有多大，值得思考！ 我往往会找一些工具，或者自己扩展一些插件来完成这样的转换 比如 pojo对象转换成dto对象 我运用到了beanutils和注解形式自己写了个工具，转换也只是一行代码而已 User user = ...... UserDTO uDTO = MyBeanUtils.convert(user,UserDTO.class); List<User> userList = ..... List<UserDTO> userDTOList = MyBeanUtils.convertList(userList,UserDTO.class); 这个肯定是必需的。但对于这样的转换，大家还是觉得有工作量。而且确实有工作量 
|
| 返回顶楼 | |
|
发表时间：2011-04-26
peterwei，我警告你，不要和搞什么扫盲。搞这么多概念了出来，结果一群不明真相的同学又出来找你辩论，搞得老子看不出那个是SB了。
不少人连远程调用都不知道。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
mercyblitz 写道 peterwei，我警告你，不要和搞什么扫盲。搞这么多概念了出来，结果一群不明真相的同学又出来找你辩论，搞得老子看不出那个是SB了。
不少人连远程调用都不知道。 哈哈。不扫，以后找谁和我说话呢。现在那些大牛们又不来喷了。所以扫一批盲出来吧。哈哈，很多人确实不了解真相，你要说，他没看过一些相关资料，他们还真不明白。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
说正题，
这里我补充说明一下，Java EE Core pattern中都提到过了。 DTO就是TO（Transfer Object），传输对象，用于远程服务调用之间的信使。可能是单一的POJO，也可以是多个组合（主要减少网络传输TCP三次握手）。从生命周期而言，属于瞬时对象，只限于传输（调用之间）作为中间转换对象或者直接对象。 PO，也是实体对象（Entity Object），字面上理解，它要实实在在存在，那么需要持久化，有一定的生命周期。 VO，可以是TO，也可以是DO，作为POJO。这方面，楼主没有补充作为DO的地方。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
mercyblitz 写道 说正题，
这里我补充说明一下，Java EE Core pattern中都提到过了。 DTO就是TO（Transfer Object），传输对象，用于远程服务调用之间的信使。可能是单一的POJO，也可以是多个组合（主要减少网络传输TCP三次握手）。从生命周期而言，属于瞬时对象，只限于传输（调用之间）作为中间转换对象或者直接对象。 PO，也是实体对象（Entity Object），字面上理解，它要实实在在存在，那么需要持久化，有一定的生命周期。 VO，可以是TO，也可以是DO，作为POJO。这方面，楼主没有补充作为DO的地方。 DO你是指什么？Domain Object?我只是针对我们大多数项目用到的情况说的。DO我确实不大了解。如果是SDO倒有过粗略的了解。你可以补充呀。 
|
| 返回顶楼 | |
|
发表时间：2011-04-26
peterwei 写道 mercyblitz 写道 说正题，
这里我补充说明一下，Java EE Core pattern中都提到过了。 DTO就是TO（Transfer Object），传输对象，用于远程服务调用之间的信使。可能是单一的POJO，也可以是多个组合（主要减少网络传输TCP三次握手）。从生命周期而言，属于瞬时对象，只限于传输（调用之间）作为中间转换对象或者直接对象。 PO，也是实体对象（Entity Object），字面上理解，它要实实在在存在，那么需要持久化，有一定的生命周期。 VO，可以是TO，也可以是DO，作为POJO。这方面，楼主没有补充作为DO的地方。 DO你是指什么？Domain Object?我只是针对我们大多数项目用到的情况说的。DO我确实不大了解。如果是SDO倒有过粗略的了解。你可以补充呀。 DO = Domain Object呀，其实有时候分不清， Domain Object == Entity Object。所以，我为了不被概念混淆，主要分为两大类：Thin Object和Rich Object。 在不同的层次叫法不同，比如DAO中，Thin Object可以叫做PO，Entity Object。在表示层传输的话，就是DO或者VO。远程调用TO。 Rich Object主要用于重用点比较少的地方，因为毕竟Rich，很多耦合。 所以，看场景用不同的O蛋。 |
| 返回顶楼 | |
|
发表时间：2011-04-26
mercyblitz 写道 peterwei 写道 mercyblitz 写道 说正题，
这里我补充说明一下，Java EE Core pattern中都提到过了。 DTO就是TO（Transfer Object），传输对象，用于远程服务调用之间的信使。可能是单一的POJO，也可以是多个组合（主要减少网络传输TCP三次握手）。从生命周期而言，属于瞬时对象，只限于传输（调用之间）作为中间转换对象或者直接对象。 PO，也是实体对象（Entity Object），字面上理解，它要实实在在存在，那么需要持久化，有一定的生命周期。 VO，可以是TO，也可以是DO，作为POJO。这方面，楼主没有补充作为DO的地方。 DO你是指什么？Domain Object?我只是针对我们大多数项目用到的情况说的。DO我确实不大了解。如果是SDO倒有过粗略的了解。你可以补充呀。 DO = Domain Object呀，其实有时候分不清， Domain Object == Entity Object。所以，我为了不被概念混淆，主要分为两大类：Thin Object和Rich Object。 在不同的层次叫法不同，比如DAO中，Thin Object可以叫做PO，Entity Object。在表示层传输的话，就是DO或者VO。远程调用TO。 Rich Object主要用于重用点比较少的地方，因为毕竟Rich，很多耦合。 所以，看场景用不同的O蛋。 Rich现在还是少的。一般都是thin.所以我一般也就是说thin object.现在基本可以定论了。感谢各位同学的参与，鸣金收兵，开始干活。
|
| 返回顶楼 | |
|
发表时间：2011-04-26
最后修改：2011-04-26
peterwei 写道 public class OrderAction{
private Order order=new Order();
private List<Order> orderList
public String add(){
orderService.add(order);
return xx;
}
public String query(){
orderList=orderService.find(Object param);
return xx;
}
}
public class OrderService{
public void add(Order){
orderDao.saveOrUpdate(Order o);
}
public List find(Object param){
return orderDao.find(Object param);
}
}
2.用VO(DTO)模式的代码示例： public class OrderService{
public void add(OrderVO vo){
Order order=new Order();
Account account=new Account();
account.setXX(vo.getXX);
//一堆XX
order.setAccount(account);
//又一堆XX
orderDao.saveOrUpdate(Order);
}
public List<OrderVO> find(Object param){
List list=orderDao.find(Object param){
for(xxxx){
//集合下的集合
//更多的XX转换
setXX
setXX
}
}
}
}
1. JavaEE各层之间解耦，这是从设计角度来说的。也就是说Domain Object(PO)直接封死在Dao层。高内聚，低耦合是我们追求的一个目标。但由于在一般的应用中大量的PO,VO转换，增加了工作量，也有些人说是过度设计。 2. 隔离变化。当在一些大型的应用场景以及Domain经常变化的系统里，View层可以只关注DTO对象，不用关心Domain层PO对象，如hibernate entity的不断变化。 3. 利于发挥个人技术特长，特别是按层来分工开发的团队。如有人专注于Web层，只做SpringMVC和界面这部分。还有人专门做Spring和Hibernate部分。两组的开发人员定义好接口数据就行，也就是DTO（VO）。我们当时做的电子商务网站就是这样的。 4. 当系统发展大后，扩展成各种前端界面后，可以有效隔离核心应用层。如又有web界面，又有swing的cs界面，又有手机客户端。 5. 当分层部署时，也就是Web层(jsp,Struts2)和App层(Spring,dao)在不同机器上时，用Remote协议通迅，DTO是必需的。如处理hibernate lazy load和序列化等问题。在电子商务应用中分层部署的主要好处是减少各层负载量，提高性能。 6. 在一些特定场景，如需要防火墙的地方，需要把核心数据层(Service,Dao,DB)放在防火墙内。 我想代码这东西你只要明白你想要什么 总会有办法解决的. 比如你的问题 set行数太多 到处重复 po到vo转换又不能省略的条件下
class XpVO{
.................
//<-----上面是一般的vo代码--->
//下面加一个构造器不就行了?
public static XpVO createFromPo(XpPo,AccentPo){
...............
}
public static XpVO changeAccentFromPo(XpPo,AccentPo){
...............
}
}
|
| 返回顶楼 | |
|
发表时间：2011-04-26
抛出异常的爱 写道 peterwei 写道 public class OrderAction{
private Order order=new Order();
private List<Order> orderList
public String add(){
orderService.add(order);
return xx;
}
public String query(){
orderList=orderService.find(Object param);
return xx;
}
}
public class OrderService{
public void add(Order){
orderDao.saveOrUpdate(Order o);
}
public List find(Object param){
return orderDao.find(Object param);
}
}
2.用VO(DTO)模式的代码示例： public class OrderService{
public void add(OrderVO vo){
Order order=new Order();
Account account=new Account();
account.setXX(vo.getXX);
//一堆XX
order.setAccount(account);
//又一堆XX
orderDao.saveOrUpdate(Order);
}
public List<OrderVO> find(Object param){
List list=orderDao.find(Object param){
for(xxxx){
//集合下的集合
//更多的XX转换
setXX
setXX
}
}
}
}
1. JavaEE各层之间解耦，这是从设计角度来说的。也就是说Domain Object(PO)直接封死在Dao层。高内聚，低耦合是我们追求的一个目标。但由于在一般的应用中大量的PO,VO转换，增加了工作量，也有些人说是过度设计。 2. 隔离变化。当在一些大型的应用场景以及Domain经常变化的系统里，View层可以只关注DTO对象，不用关心Domain层PO对象，如hibernate entity的不断变化。 3. 利于发挥个人技术特长，特别是按层来分工开发的团队。如有人专注于Web层，只做SpringMVC和界面这部分。还有人专门做Spring和Hibernate部分。两组的开发人员定义好接口数据就行，也就是DTO（VO）。我们当时做的电子商务网站就是这样的。 4. 当系统发展大后，扩展成各种前端界面后，可以有效隔离核心应用层。如又有web界面，又有swing的cs界面，又有手机客户端。 5. 当分层部署时，也就是Web层(jsp,Struts2)和App层(Spring,dao)在不同机器上时，用Remote协议通迅，DTO是必需的。如处理hibernate lazy load和序列化等问题。在电子商务应用中分层部署的主要好处是减少各层负载量，提高性能。 6. 在一些特定场景，如需要防火墙的地方，需要把核心数据层(Service,Dao,DB)放在防火墙内。 我想代码这东西你只要明白你想要什么 总会有办法解决的. 比如你的问题 set行数太多 到处重复 po到vo转换又不能省略的条件下
class XpVO{
.................
//<-----上面是一般的vo代码--->
//下面加一个构造器不就行了?
public static XpVO createFromPo(XpPo,AccentPo){
...............
}
public static XpVO changeAccentFromPo(XpPo,AccentPo){
...............
}
}
老抛说的肯定是要有的，我们封装了beanutils。但是即使封装了，别人还是觉得麻烦嘛。 |
| 返回顶楼 | |
