Java web 开发中 Maven 是不可或缺的管理组件,贯穿代码骨架工程搭建,依赖管理,测试,打包以及二方库发布等环节.然而,使用 Maven 搭建骨架工程时,模块的划分并没有统一标准,于是我经历过的项目组看到了两个极端的划分.其一:大一统,一个 pom 模块加一个 web 模块,基本丧失了模块管理的作用;其二:划分过细,层层嵌套,增加了开发工作的复杂性.那如何在这两个极端中找到平衡方案呢?本文我从以下两个方面做了阐述,欢迎大家批评指正.
01 Java Web 分层开发模式概述
分层模式是比较经典的开发模式,我试着从分层模式的特点,找到我们模块划分的依据.通常我们的系统是基于用户请求和响应进行交互的,从用户发出请求,到系统做出响应,在分层开发模式下,java 代码的执行过程如下图所示.
1-1 分层开发模式请求 & 响应示意图
基于响应链的过程(基于请求链也无不可),从持久化数据库(后)到用户 UI 界面(前),我们可以粗略的将 java 代码做 Dao,Service 和 Controller 三层划分.
1-2 三层划分示意图
而通常 Controller 的作用无外乎:
1)请求转发(route)
2)视图渲染(view render)
因此,业务逻辑的实现最终会放到 Service 和 Dao 层.从这个意义上来讲,我们可以进一步抽象,将系统划分为 web 层和业务逻辑处理层(Service).
1-3 进一步抽象的两层划分示意图
其实作为主流的 J2EE 框架,SpringMvc 容器也是按照这两层来划分的,每个 DispatchServlet 实例都有自己的上下文,且持有 spring 父容器的上下文.
1-4 springMvc 的父子容器示意图
02 Service 层的 "开放 - 闭合" 原则(OCP)
说是原则,不如说是我们软件开发过程追求的目标
面向扩展开放(Open For Extension)
面向修改封闭(Closed For Modification)
那实现这个目标的具体手段有哪些呢?在我看来就是我们一直倡导的——面向接口,隐藏实现.这里不再论述这个原则的好处,接下来进入正题,来讲基于以上两点的分析,我们得出来的模块划分方案.
2-1 POM&Intf&Impl&Web 四模块示意图
通过这样的模块划分以及依赖关系,我认为至少有以下三个好处.
首先,我们从模块的可见性就很好的对 Web 隐藏了实现(就如图 1-2 经典的三层划分而言,Dao 也对 Service 隐藏了实现),继而实现面向接口的编程.
再者,在团队协作开发过程中,即时没有实现,只要抽象好了接口(加好注释),在业务模块互相引用的场景下,也可以并行开发,从而提高开发效率.
最后,相对于层层嵌套的方案,这样扁平化的模块划分,降低了骨架工程和依赖管理的复杂度.
说道这里,我想就面向接口,隐藏实现展开论述一下.
a 区分(接口)能力和(实现)表现
我们在转换需求的时候,必须要能很好的识别出需求中的能力.比如拿 "金拱门" 为例,可以把它的能力和表现抽象为下面的层次.
a1 对金拱门能力和表现的抽象示意图
b 对能力的 "扩充式扩展和增量式扩展"
我们依然拿金拱门为例:
b1 能力面临扩展
那按照图 b1 的表述,我们可以这么实现:
b2 对能力的 "扩充式扩展" 示意图
如图,我们为 orderMeal 接口增加了参数 "是否需要打包"(这样比需不需要都打包要好那么一点儿),在 OrderMealServiceIntf 接口的下面,又抽象出了一个基类 OrderAndPackaageServiceAb,由它作为模版来决定是否对食物进行打包.乍一看没有什么问题,但是如果此时用户就 "一起打包" 和 "分开打包" 提出需求,那我们就只能再增加参数,并且在 OrderAndPackaageServiceAb 中去增加实现了.但是如果我们采用 "增量式扩展",则不会有这个问题.
b3 对能力的 "增量式扩展" 示意图
在这种扩展方式中,我们将 "打包" 抽象成了一个能力 MakePackageServiceIntf,由它作为委托,实现 TakeAwayOrderMealService 的打包需求.通过这个例子,我们还可以得出以下两个论点:
扩展接口职责尽可能单一,这样才具有可组合性
继承是生死相依,委托是逢场做戏(多交男女朋友,少认干爹干娘)
来源: http://www.jianshu.com/p/9ef2005a0001