java的几种对象(PO,VO,DAO,BO,POJO)解释(转).pptVIP

java的几种对象(PO,VO,DAO,BO,POJO)解释 一、PO:persistant object 持久对象,可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。 二、VO:value object值对象。通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递。 三、DAO:data access object 数据访问对象，此对象用于访问数据库。通常和PO结合使用，DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作。 四、BO:business object 业务对象,封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作。 五、POJO:简单的Java对象（Plain Old Java Objects）实际就是普通JavaBeans,使用POJO名称是为了避免和EJB混淆起来, 而且简称比较直接. 其中有一些属性及其getter setter方法的类,有时可以作为value object或dto(Data Transform Object)来使用.当然,如果你有一个简单的运算属性也是可以的,但不允许有业务方法,也不能携带有connection之类的方法。 或者POJO:plain ordinary java object 简单无规则java对象。 VO 和 PO 有一种观点就是：PO只能用在数据层，VO用在商业逻辑层和表示层。各层操作属于该层自己的数据对象，这样就可以降低各层之间的耦合，便于以后系统的维护和扩展。如果将PO用在各个层中就相当于我们使用全局变量，我们知道在OO设计非常不赞成使用全局变量。? ???????但是每次都得进行VO-PO的转换，也确实很烦。我觉得有时候也可以在某个商业逻辑或者表示层使用PO，此时在这个商业逻辑的过程中PO的状态是不发生变化的，比如显示一条商品详细信息的商业逻辑。? ???????在开发过的项目中，规模都很小，我一直都把PO当VO用，因为PO确实很方便，结合Hibernate的DAO，我使用JAVA的集合对象作为值传递的载体，当然Struts也是我的不二之选。? ???????我认为：在一些直观的，简单的，不易发生变化的，不需要涉及多个PO时，传递值还是使用PO好，这样可以减少大量的工作量（也就意味着减少bug，减少风险），也不需要担心未来的维护工作!? VO和POJO POJO是指最最传统的Java对象，和任何模式都无关。Value Object是指某一种特定的设计模式,两者不是一个层次的概念。 “支持POJO”至少包括两层意思： 1. 简化开发，程序员按照传统的OO方法进行编程，不需要为某个对象设计多个接口或辅助类。例如一个简单的User类，既可以用来做持久化，也可以用来在界面显示，也可以用来传输，不需要再有VO，PO这些概念之分。2. 打破特定框架的藩篱，最大程度地复用代码。在Java里面，有无数的框架，绝大多数要求你按照某种规范进行编程，实现某个接口，或者继承某个特定类。这种规范，在该框架内部是有益的，但是如果框架被淘汰，对原有代码的打击也是毁灭性的。其实，Java里最稳定的框架有一个，就是Java Bean。如果各种Java技术能够在这个层次上集成，对于程序员来说将是最有利的。Hibernate和Glue WebServices都是这样的技术。 PO和POJO 持久对象实际上必须对应数据库中的entity，所以和POJO有所区别。比如说POJO是由new创建，由GC回收。但是持久对象是insert数据库创建，由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库Connection之中，Connnection关闭以后，持久对象就不存在了，而POJO只要不被GC回收，总是存在的。 由于存在诸多差别，因此持久对象PO(Persistent Object)在代码上肯定和POJO不同，起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要PO在使用上尽量和POJO一致，对于程序员来说，他们可以把PO当做POJO来用，而感觉不到PO的存在。 对象序列化 这个序列化接口没有任何方法和域，仅用于标识序列化的语意。 就是可以把对象存到字节流，然后可以恢复！Integer实现了Serializable,所以可以把一个Integer的对象用IO写到文件里，之后再可以从文件里读