运用ViewObject收集信息，利用DTO传递信息

信息的处理需要经过三大步骤 收集、加工、传递。在 J2EE 体系中，也是如此，总的来说可以如下：

收集：接受来自页面的数据，组装数据到页面，验证数据有效性，装配数据。

加工：进行业务处理，产出各种数据。

传递：组装数据 , 并转为各种格式，传送到目的地。

对于 J2EE 来说：

收集环节集中在视图层。在编程中，最常见的错误就是赋予控制器类过于强大，具体为表现：

1 、引入业务逻辑，导致页面一动，业务逻辑也动。

2 、在向页面传递参数时，既做组装，又做查询，导致职责混乱，不易扩展。

我认为，在这一环节，需要把收集的工作委托给 ViewObject ，并赋予它各种功能，除了修改。

理由如下：

              减轻控制类的负担，让控制类更加单一。

              ViewObject 是页面的数据容器，把判断功能和查询功能转移到 ViewObject ，可以有效地减少 JS 代码量。

              ViewObject 可以防止页面逻辑渗透到业务逻辑层。

 

如何编写 ViewObject ？

              1、   仔细观察原型图，对数据进行分类、归纳。

              2、   为每一种概念建立 ViewObject, 再把每个小小的 ViewObject 组装成复合 ViewObject 。

              3、   仔细思考，考虑 ViewObject 中的属性可以生成哪些领域对象（ DomainObject ），然给 ViewObjec 添加 CreateXXXX 等方法，或者引入 Factory 模式，解耦 DomainObject 和 ViewObject 。

             4、   为 ViewObject 增加验证函数。一来可以控制页面的流转。二来降低页面复杂度。

             5、   为 ViewObject 增加 Query 函数。这里 Query 函数不是持久层的查询函数，而是针对集合的查询函数。比如 order.getTotalPrice() ， item.totalPrice() 。在页面上只要写上“ ${order.totalPrice} ”即可获取总价。

 

加工环节不是本文重点。略过 ……………………………

 

在传递环节，常见的错误就是把组装和转化耦合在一起。

举个例子：某系统要把客户订购的商品，配送，支付，优惠等订单信息。以邮件、传真、页面的形式呈现在客户眼前。

我看到的错误做法是：

             1、   写一个邮件模板，写一个 XMlEmailUtil 类。

             2、   写一个订单信息页，写一个 ViewOrderInfo 的控制类方法。

             3、   写一个传真模板，写一个 XMLFaxUtil 类。

这样做存在以下几个风险：

              如果系统决定采用 JSON 格式把订单信息传递给第三方，那么就要在写一个 JsonUtil 类

              如果需在订单信息中增加物流信息，那么需要修改 3 个类，三个模板。

正确的做法是：把组装和转化分离。

仔细想想，在信息传递过程中，内容一般不变，通过是表现形式和载体发生了变化。所以要把组装和转化分开，做到“一个组装，多次转化”，修改量也就大大降低。

 

如何实现：

            1、   创建 OrderDTO ，内容为所谓要的数据。

            2、   创建 DTOFactory 类 , 添加上 toOrderDTO 方法，用于组装 OrderDTO 类。

            3、   创建 XmlOrderBuilder ，根据 OrderDTO ，组装 Xml 数据。

            4、   创建 JsonOrderBuilder ，根据 OrderDTO ，组装 Json 数据。

最后不要忘了引入 TDD 。

 

     当然，也有人会问，为什么要写这么多类，太复杂了。我的意见是看需求。假如说，系统只需要把订单信息显示在浏览器上，就不用花时间写来这些代码。万一不是呢，我想这些可以助你一臂之力。

 

       后记：

       其实，这篇文章是在与同事的聊天过程中想到的。多多交流才会碰撞出火花。沟通交流必不可少。