基于maven的java web项目模块管理最优方案

综合编程 简书

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的打包需求。通过这个例子,我们还可以得出以下两个论点:

扩展接口职责尽可能单一,这样才具有可组合性

继承是生死相依,委托是逢场做戏(多交男女朋友,少认干爹干娘)

简书稿源:简书 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合编程 » 基于maven的java web项目模块管理最优方案

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录