关于模型的理解

此文不是原创，是来自于讲师-张小喜老师的分享，觉得老师讲的通俗易懂，所以记录下来

那应用系统为什么要分层呢？

 

其实主要是解决一下几个问题：

第一：解耦

有一句计算机名言：软件的所有问题都可以通过增加一层来解决。

当系统越大，团队越多，需求变化越快时，越需要保证程序之间的依赖关系越少。而分层/面向接口编程，会使我们在应对变化时越容易。

 

第二：简化问题

当我们想不明白从用户操作一直到数据落盘整个过程的交互情况时，我们应该换种方式思考。想想各层应该提供哪些支持，通过对各层分工的明确定义，复杂问题就变成了如何将各层功能组合起来的“积木搭建”。

 

第三：降低系统维护与升级成本

这里体现了面向接口编程的优势。我们抽象出数据访问层后，只需要保证对外提供的接口不变，底层数据库使用Oracle还是MySql，上层结构是感知不到的。

 

第四：逻辑复用/代码复用

通过分层，明确定义各层职责，再也不会出现系统中多个地方查询同一个数据库表的代码。因为查询某个数据库表的工作只会由一个数据访问层类来统一提供。

 

第五：提高团队开发效率

如果开发团队很多，通过分层和接口定义。各团队只需要遵循接口标准/开发规范，就可以并行开发。

有一个形容比较贴切：分层化相当于把软件横向切几刀，模块化相当于把软件纵向切几刀。

开放接口层：可直接封装Service方法暴露成RPC接口；通过Web封装成http接口；进行网关安全控制/流量控制等。

终端显示层：各个端的模版渲染并执行显示的层。当前主要是velocity渲染，JS渲染，JSP渲染，移动端展示等。

Web层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

Service层：相对集体的业务逻辑服务层。

Manager层：通用业务处理层，它有如下特征：

1.  对第三方平台封装的层，预处理返回结果及转化异常信息。
2. 对Service层通用能力的下沉，如缓存方案/中间件通用处理
3.  与DAO层交互，对多个DAO的组合复用。

 

DAO层：数据访问层，与底层MySQL、Oracle、HBase等进行数据交互。

外部接口或第三方平台：包括其他部门RPC开放接口，基础平台，其他公司的HTTP接口。

以上的层级只是在原来三层架构的基础上进行了细分，而这些细分的层级仅仅是为了满足业务的需要。千万不要为了分层而分层。过多的层会增加系统的复杂度和开发难度。

DO(Data Object)：此对象与数据库表结构一一对应，通过DAO层想上传输数据源对象。

DTO(Data Transfer Object)：数据传输对象，Service或Manager向外传输的对象。

BO(Business Object)：业务对象，由Service层输出的封装业务逻辑的对象。

AO(Application Object)：应用对象，在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。

VO(View Object)：显示层对象，通常是Web向模版渲染引擎层传输的对象。

Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

在给出的参考中并没有对模型对象进行非常明确的划分，特别是对BO、AO、DTO的界限不是非常明确。这也是因为系统处理的业务不同、复杂度不同导致的。所以在设计系统分层和建模的时候，需要综合考虑实际应用场景。

 

比如你查询自己网上购物的订单，可能会在网页上看到这样的信息

其中包含：订单编号，下单日期，店铺名称，用户信息，总金额，支付方式，订单状态还有一个订单商品明细的集合。

对终端显示层来说，这些信息是可以封装成一个VO对象的。因为显示层的关注点就是这些信息。为了方便显示层展示，我们可以将所有属性都弄成字符串类型。

可以看到，下单日期使用的Date类型，金额使用BigDecimal，支付方式和订单状态使用枚举值表示，商铺名称和用户名称变成了商铺信息/用户信息对象，明细集合中的商品也变成了DTO类型的对象。

 

做为测试和讲解的案例，咱们就以上面说到的OrderDTO转OrderVO为例，来说说下面的各种方法。

 

 

我们期待他转换成这样

先来看第一种方法：也是最简单粗暴的方法，直接通过Set/Get方式来进行人肉赋值。代码我就不贴了，相信大家都会。

说一说它的优缺点：
优点：直观，简单，处理速度快
缺点：属性过多的时候，人容易崩溃

第二种：FastJson

利用序列化和反序列化，这里我们采用先使用FastJson的toJSONString的方法将原对象序列化为字符串，再使用parseObject方法将字符串反序列化为目标对象。

但是他的效果没有我们想象中的那么好

可以看到

- 日期不符合我们的要求
- 金额也有问题
- 最严重的是，当属性名不一样时，不复制

第三种：Apache工具包PropertyUtils工具类

但是报错了

- 属性类型不一样，报错
- 不能部分属性复制
- 得到的目标对象部分属性成功(这点很要命，部分成功，部分失败！)

 

第四种：Apache工具包BeanUtils工具类

 日期不符合要求
- 属性名不一样时不复制
- 目标对象中的商品集合变成了DTO的对象，这是因为List的泛型被擦除了，而且是浅拷贝，所以造成这种现象。

第五种：Spring封装BeanUtils工具类

 

 

apache的`BeanUtils`和spring的`BeanUtils`中拷贝方法的原理都是先用jdk中 `java.beans.Introspector`类的`getBeanInfo()`方法获取对象的属性信息及属性get/set方法，接着使用反射（`Method`的`invoke(Object obj, Object... args)`）方法进行赋值。

前面五种都不能满足我们的需要，其实想想也挺简单。对象转换本来就很复杂，人工不介入很难做到完美转换。

 

 

Dozer支持简单属性映射、复杂类型映射、双向映射、隐式映射以及递归映射。可使用xml或者注解进行映射的配置，支持自动类型转换，使用方便。

它的特点如下：
- 支持多种数据类型自动转换（双向的）
- 支持不同属性名之间转换
- 支持三种映射配置方式（注解方式，API方式，XML方式）
- 支持配置忽略部分属性
- 支持自定义属性转换器
- 嵌套对象深拷贝

介绍的这些转换方法中，在性能上基本遵循：手动赋值 > cglib > 反射 > Dozer > 序列化。

在实际项目中，需要综合使用上述方法进行模型转换。

比如较低层的DO，因为涉及到的嵌套对象少，改动也少，所以可以使用BeanUtils直接转。

如果是速度、稳定优先的系统，还是乖乖使用Set、Get实现吧。