OO之间的大PK

原来在.NET项目中使用如下的架构图：

以上的架构图就是一个简单的三层架构，可以在此添加接口层，这个暂时不考虑。单说以上的架构图，无论怎么看，也没有看出什么问题，并且从来也没有怀疑过此架构的设计，因为网上大多数以及自己的项目实践中都是这么操作的。

 

但是在接触java项目中，自己设计的架构图也是类似的，直接把.NET中的分层思想搬过来，结果被上司又一番说道。经过交流，发现确实上述的设计还是有缺陷的。经过一番思考后，整理如下：

 

首先声明，以上的架构图，总体来说，是没问题的并且对于初学者已经是很好的分层架构了。

但是仔细研究后，缺陷如下，缺陷在于Entity类。

一、存在资源浪费。

        平常设计中，一般Entity是与数据库表对应的，假若某表中有10个属性，而界面中只是用2个属性，那么查询的实体，则携带10个属性，从数据访问层DAL一直携带到WEB层。携带必须占用相应的空间吧。所以浪费了没有必要的内存空间，这点平常是大家都不怎么在乎的，但是作为一个负责的开发者，这点必须重视起来。

二、存在安全隐患。

         还是刚才那个例子，表中有10个属性字段，界面只有2个，但是查询的实体，携带了全部。查询的实体，则暴露了数据表，那么肯定会出现有意或无意破坏数据库表想象。

三、存在数据耦合

         刚才的例子，既然暴露数据表，那我们想把数据表独立出来，然后封装起来，可以不？这点可以做到，但是对于上述架构图，这点是做不到的，因为每层都需要依赖Entity，所以无法把Entity独立出来。

 

那既然存在问题，肯定会有解决问题的办法。因为只有推出新的解决方案才敢推翻旧的设计方案。

这就得由各种OO出面解决了。通常所说的专业术语PO，BO，VO，DTO都是什么东东，在此一一解释其含义并适用的场合。

PO：persistent object ：持久化对象。通俗的说，就是与数据表一一对应的。PO对象中只有数据，getset方法，没有其他的行为。主要应用于数据访问层。

BO：business object   ：业务逻辑对象。通俗的说，是用来封装业务逻辑的。BO对象中主要是业务逻辑方法。比如填写一个大学生毕业档案，其中档案中包括社会关系，家庭关系。在此例子中，社会关系就是一个PO,家庭关系一个PO，而填写毕业档案就是一个BO,BO 是对社会关系PO和家庭关系PO的封装。主要应用于业务逻辑层。

VO：value object       ：值对象。通俗的说，就是为页面显示数据的。主要应用于界面层。

DTO：data translate object:数据转化对象。根据字面意思就可以推断出其出现的目的。比如还是上述那个问题，10个属性只用到2个属性，如何办，这个时候就用到DTO来转化了。主要是应用于前台和后台转化数据的。

当然还有一个常说的POJO对象。其实POJO对象就是一个javabean，javabean就是一个简单纯洁的java实体对象，没有继承或实现任何对象，并且只有getset方法。其实po对象就是一个pojo对象。只不过po概念是在orm映射下提出的，若没有orm，则po不存在。

 

根据上述，架构图进一步改进如下：

 

其中DTO对象在图中没有体现。我们用文字描述一下流程：

DAO层从数据库中获得数据，转化成PO，然后业务逻辑层把PO封装成BO，然后BO对象转化成DTO,再由DTO转成界面所需的VO。

反之亦然。提取界面的数据，封装成VO，然后转换成DTO,然后传给业务逻辑层BO,然后继续向下传给DAO层的PO ,最后存储到数据库中。

其实po，vo，bo，dto这些名词的出现，只是为了帮助我们的理解，没有必要非得按照严格的规范设计，还是那一句话：适合就是最好的！

 

  Ps:po，vo，bo，dto，这些都是java中概念对象。上述的架构图只是为了说明各种O的概念以及适合的场合。一般情况下java项目中的架构设计数据访问层都是DAO 业务逻辑层都是Service。