转贴一个关于DTO DAO VO BO PO POJO的^_^

DTO DAO VO BO PO POJO- -

                                      

potian 写道:

辨别一些名词： 1。VO：实际上很模糊，通常指ValueObject和ViewObject 2. ViewObject，界面展现需要的对象，如Struts的FormBean 3。Value Object，早期被作为ValueObject和Transfer Object的总称。实际上Value Object的真正意义在于它的内容，而不是身份 4。Transfer Object：数据传输对象，在应用程序不同层次之间传书对象，在一个分布式应用程序中，通常可以提高整体的性能 5。PO：也许就是Persistent Object，基本上就是Entity了 在不同的体系结构和实现方式里面，这些对象有可能重复，也有可能不重叠。如果你要做一个对所有的体系都能够方便移植的框架，那么每一种对象都需要严格区分。例如JDO的PO不能作为TO，应为它不能脱离PM，譬如你可以选择用ViewObject（如Struts的FOrmBean)直接作为TO，但在tapestry和Webwork里面就不合适了。但在很多时候，能够方便实用是最重要的，不要过度设计就是了。 robbin写道： POJO是这样一个对象，它是一个普通的Java对象，它不同于EJB这样的带有繁重的容器控制功能的对象，它也不是那种被Enhanced过的对象，例如JDO的静态Enhance，也不是类似Hibernate那样被动态的byte code generation过。 也就是说POJO的概念是相对于其他那种被人动过手脚的class而言的，它是没有被动过手脚的。 曹晓钢 其实，为什么要做DAO?无非是： 1， 管理connection/transaction (hibernate的话就是session/transaction) 2, 便于进行统计/log操作； 3， 便于进行权限控制； DAO模式中，有两类对象，一种是DAO，一种是valueObject。 在我们讨论的这个情况中，value object是hibernate对应的POJO. 那么，按照我的理解，DAO就是一个Transaction包装器，其逻辑结构就是商业的具体事务。此处，数据库的transaction和商业的事务是统一的。 这里有一篇不错的关于DAO的文章。 http://www-106.ibm.com/developerworks/java/library/j-dao/

BO 包含business logic

留在这备忘。

 

http://www.aspectoriented.org:9080//space/2004-04-22#DTO?_我需要吗？

potian写道：

DTO? 我需要吗？

我手头上有两个项目，一个是我自己做的宾馆订房，另一个是和WeiHello一起构造他们的远程框架。

DTO的需求来源于两个方面，第一：

• 我们的对象可能被某些框架或产品改变，附带某些服务端的系统资源，这些资源传输到远端以后毫无疑义，使得这些对象不能操作。JDO是一个典型的例子，它会增强对象，附带一个PersistenceManager。
• 我们对象实现了remote接口，因此在RMI，所有对这些对象进行存取都会引发远程过程调用。这在性能上是不可接受的。

因此,DTO数据传输对象是为了在不同的进程空间传输数据。象第一个问题，如果我们的web应用和我们的业务代码在同一个进程空间，那么使用OpenPersistenceManagerInView模式应该可以解决。

但是DTO也造成了非常多的问题：

• 对象数据化，DTO通常是纯数据，很少会附带业务，只是一堆数据
• 对象平板化，DTO很少包含整个对象结构图，不然在Service端的解析和生成将非常复杂

也就是，我们很难把DTO当作真正的对象，而通常service就好像是几个函数，负责操纵DTO，标准的数据和行为分离。

我们的view在使用DTO改变系统信息时，只能存取平板的数据。传给service，每次service转发给DTOFactory进行翻译工作，反之每次service通过DAO取到的对象需要经过DTOFactory翻译成DTO平板数据，这个工作量非常之大。特别对于对象包含其他对象的情况，我们完全没办法直接使用这些对象本身提供的存取方法，而是必须用addXXX(long 包含对象的id,XXXDTO dto)这样的方法进行操作。

对于分布式应用程序来说（例如weihello的远程框架），这是一件无可奈何的事情。但是对于一个不需要分布的程序而言（注意不是集群），这是不是还有需要。粗略估计，至少在90%的Web应用程序不需要分布处理，也就是完全可以把业务代码和view放在同一个JVM中。

因此，我已经再也不愿意为了一个永远不可能分布的程序去实现这么一大堆DTO，结果就是我的代码减少到50%左右，我的所有代码可以非常简洁、OO的使用。感谢Hibernate的POJO持久和OGNL的强大功能。

万一我的程序在同一台服务器上负载过大怎么办，第一步是分离数据库服务器和应用服务器，因为应用服务器大量占用CPU的时候数据库服务器必定在CPU的低潮，反之亦然。这可以大大增加负载能力。我可以集群和负载均衡，当然还是不需要分布式处理。

如果我的应用程序负载到了这样也没办法解决，必须把每个部件分离到不同的机器上进行集群的时候，我再来考虑DTO。