精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2011-06-13
最后修改:2011-06-18
信息的处理需要经过三大步骤 收集、加工、传递。在 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 。
当然,也有人会问,为什么要写这么多类,太复杂了。我的意见是看需求。假如说,系统只需要把订单信息显示在浏览器上,就不用花时间写来这些代码。万一不是呢,我想这些可以助你一臂之力。
后记: 其实,这篇文章是在与同事的聊天过程中想到的。多多交流才会碰撞出火花。沟通交流必不可少。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
浏览 1452 次