博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SSM(十) 项目重构-互联网项目的Maven结构
阅读量:7089 次
发布时间:2019-06-28

本文共 4617 字,大约阅读时间需要 15 分钟。

前言

很久没有更新博客了,之前定下周更逐渐成了月更。怎么感觉像我追过的一部动漫。 这个博文其实很早就想写了。 之前所有的代码都是在一个模块里面进行开发,这和maven的理念是完全不相符的,最近硬是抽了一个时间来对项目的结构进行了一次重构。

前言

很久没有更新博客了,之前定下周更逐渐成了月更。怎么感觉像我追过的一部动漫。 这个博文其实很早就想写了。 之前所有的代码都是在一个模块里面进行开发,这和maven的理念是完全不相符的,最近硬是抽了一个时间来对项目的结构进行了一次重构。

互联网项目的maven.jpg

先来看看这次重构之后的目录结构

1.jpg

为什么需要分模块

至于为什么要分模块呢?

我们设想一个这样的场景: 在现在的互联网开发中,会把一个很大的系统拆分成各个子系统用于降低他们之间的耦合度。

在一个子项目中通常都会为APIWEBService等模块。 而且当项目够大时,这些通常都不是一个人能完成的工作,需要一个团队来各司其职。

想象一下:当之前所有的项目都在一个模块的时候,A改动了API,需要Deploy代码。而B也改动了service的代码,但并没有完全做完。所以A在提交build的时候就会报错

而且在整个项目足够大的时候,这个build的时间也是很影响效率的。

但让我将各个模块之间分开之后效果就不一样了。我修改了API我就只需要管我的就行,不需要整个项目进行build

而且当有其他项目需要依赖我这个API的时候也只需要依赖API即可,不用整个项目都依赖过去。

各个模块的作用

来看下这次我所分的模块。

ROOT

这是整个项目的根节点。 先看一下其中的pom.xml

 
  1. <groupId>com.crossoverJie</groupId> 
  2.     <artifactId>SSM</artifactId> 
  3.     <packaging>pom</packaging> 
  4.     <version>2.0.0</version> 
  5.  
  6.     <modules> 
  7.         <module>SSM-API</module> 
  8.         <module>SSM-BOOT</module> 
  9.         <module>SSM-SERVICE</module> 
  10.         <module>SSM-WEB</module> 
  11.     </modules> 
  12.  
  13.     <properties> 
  14.         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
  15.         <spring.version>4.1.4.RELEASE</spring.version> 
  16.         <jackson.version>2.5.0</jackson.version> 
  17.         <lucene.version>6.0.1</lucene.version> 
  18.     </properties> 
  19.  
  20.  
  21.     <dependencyManagement> 
  22.  
  23.         <dependencies> 
  24.             <dependency> 
  25.                 <groupId>com.crossoverJie</groupId> 
  26.                 <artifactId>SSM-API</artifactId> 
  27.                 <version>2.0.0</version> 
  28.             </dependency> 
  29.          </dependencies> 
  30.     </dependencyManagement> 

我截取了其中比较重点的配置。

由于这是父节点,所以我的packag类型使用的是pom。 其中分别有着四个子模块。

其中重点看下<dependencyManagement>这个标签。 如果使用的是IDEA这个开发工具的话是可以看到如下图:

2.jpg

标红的有一个向下的箭头,点一下就可以进入子模块中相同的依赖。 这样子模块就不需要配置具体的版本了,统一由父模块来进行维护,对之后的版本升级也带来了好处。

SSM-API

接下来看下API这个模块:

通常这个模块都是用于定义外部接口的,以及改接口所依赖的一些DTO类。 一般这个模块都是拿来给其他项目进行依赖,并和本项目进行数据交互的。

SSM-BOOT

BOOT这个模块比较特殊。 可以看到这里没有任何代码,只有一个rpc的配置文件。 通常这个模块是用于给我们内部项目进行依赖的,并不像上面的API模块一样给其他部门或者是项目进行依赖的。

因为在我们的RPC调用的时候,用dubbo来举例,是需要配置所依赖的consumer

但如果是我们自己内部调用的话我们就可以把需要调用自己的dubbo服务提供者配置在这里,这样的话我们自己调用就只需要依赖这个BOOT就可以进行调用了。

哦对了,BOOT同时还会依赖API,这样才实现了只依赖BOOT就可以调用自己内部的dubbo服务了。 如下所示:

 
  1. <dependencies> 
  2.         <dependency> 
  3.             <groupId>junit</groupId> 
  4.             <artifactId>junit</artifactId> 
  5.             <scope>test</scope> 
  6.         </dependency> 
  7.  
  8.         <dependency> 
  9.             <groupId>com.crossoverJie</groupId> 
  10.             <artifactId>SSM-API</artifactId> 
  11.         </dependency> 
  12.  
  13.     </dependencies> 

SSM-SERVICE

SERVICE模块就比较好理解了。 是处理具体业务逻辑的地方,也是对之前的API的实现。

通常这也是一个web模块,所以我的pom类型是WAR

SSM-WEB

其实WEB模块和SERVICE模块有点重合了。通常来说这个模块一般在一个对外提供http访问接口的项目中。

这里只是为了展示项目结构,所以也写在了这里。

他的作用和service差不多,都是WAR的类型。

总结

这次没有实现什么特别的功能,只是对一些还没有接触过这种项目结构开发的童鞋能起到一些引导作用。

具体源码还请关注我的github

项目地址:

个人博客地址:。

GitHub地址:。

先来看看这次重构之后的目录结构

1.jpg

为什么需要分模块

至于为什么要分模块呢?

我们设想一个这样的场景: 在现在的互联网开发中,会把一个很大的系统拆分成各个子系统用于降低他们之间的耦合度。

在一个子项目中通常都会为APIWEBService等模块。 而且当项目够大时,这些通常都不是一个人能完成的工作,需要一个团队来各司其职。

想象一下:当之前所有的项目都在一个模块的时候,A改动了API,需要Deploy代码。而B也改动了service的代码,但并没有完全做完。所以A在提交build的时候就会报错

而且在整个项目足够大的时候,这个build的时间也是很影响效率的。

但让我将各个模块之间分开之后效果就不一样了。我修改了API我就只需要管我的就行,不需要整个项目进行build

而且当有其他项目需要依赖我这个API的时候也只需要依赖API即可,不用整个项目都依赖过去。

各个模块的作用

来看下这次我所分的模块。

ROOT

这是整个项目的根节点。 先看一下其中的pom.xml

com.crossoverJie
SSM
pom
2.0.0
SSM-API
SSM-BOOT
SSM-SERVICE
SSM-WEB
UTF-8
4.1.4.RELEASE
2.5.0
6.0.1
com.crossoverJie
SSM-API
2.0.0

我截取了其中比较重点的配置。

由于这是父节点,所以我的packag类型使用的是pom。 其中分别有着四个子模块。

其中重点看下<dependencyManagement>这个标签。 如果使用的是IDEA这个开发工具的话是可以看到如下图:

2.jpg

标红的有一个向下的箭头,点一下就可以进入子模块中相同的依赖。 这样子模块就不需要配置具体的版本了,统一由父模块来进行维护,对之后的版本升级也带来了好处。

SSM-API

接下来看下API这个模块:

通常这个模块都是用于定义外部接口的,以及改接口所依赖的一些DTO类。 一般这个模块都是拿来给其他项目进行依赖,并和本项目进行数据交互的。

SSM-BOOT

BOOT这个模块比较特殊。 可以看到这里没有任何代码,只有一个rpc的配置文件。 通常这个模块是用于给我们内部项目进行依赖的,并不像上面的API模块一样给其他部门或者是项目进行依赖的。

因为在我们的RPC调用的时候,用dubbo来举例,是需要配置所依赖的consumer

但如果是我们自己内部调用的话我们就可以把需要调用自己的dubbo服务提供者配置在这里,这样的话我们自己调用就只需要依赖这个BOOT就可以进行调用了。

哦对了,BOOT同时还会依赖API,这样才实现了只依赖BOOT就可以调用自己内部的dubbo服务了。 如下所示:

junit
junit
test
com.crossoverJie
SSM-API

SSM-SERVICE

SERVICE模块就比较好理解了。 是处理具体业务逻辑的地方,也是对之前的API的实现。

通常这也是一个web模块,所以我的pom类型是WAR

SSM-WEB

其实WEB模块和SERVICE模块有点重合了。通常来说这个模块一般在一个对外提供http访问接口的项目中。

这里只是为了展示项目结构,所以也写在了这里。

他的作用和service差不多,都是WAR的类型。

总结

这次没有实现什么特别的功能,只是对一些还没有接触过这种项目结构开发的童鞋能起到一些引导作用。

作者:crossoverJie

来源:51CTO

转载地址:http://mvbql.baihongyu.com/

你可能感兴趣的文章
跟着ALEX 学python day4集合 装饰器
查看>>
PHP跳转页面的几种实现方法详解
查看>>
获取相机视口内物体在视线范围内某点的方法
查看>>
解疑常用
查看>>
新手搭建 eclipse+winDDK驱动开发平台
查看>>
二叉树面试题
查看>>
Max Sum 贪心
查看>>
算法小题之数组重排
查看>>
Session 跨页面传数组
查看>>
Java并发(基础知识)——显示锁和同步工具类
查看>>
二叉树(2)二叉树创建的3种方法,二叉树的递归遍历,二叉树的销毁
查看>>
DBA常用的脚本---三-ORACLE常用技巧和脚本
查看>>
awk的思维导图
查看>>
哪本书是对程序员最有影响、每个程序员都该阅读的书?
查看>>
201521123081《java程序设计》 第12周学习总结
查看>>
cloneNode克隆节点在不同浏览器的差异
查看>>
Tomcat的启动与关闭以及启动时一闪而过的解决方法
查看>>
动作Action
查看>>
git 怎么上传文件到github上
查看>>
curl myip.ipip.net curl ip.cn curl cip.cc
查看>>