您好,登录后才能下订单哦!
如何进行maven模块划分实践,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
我们平常做的java项目模块划分可能是这样:
controller为控制器层;service为业务逻辑实现层;dao和数据库交互;util放些工具类;constant放常量类。
这样的模块划分很常见,但是有很多弊端:
1、当随着项目版本迭代,需求不断增加,代码结构越来越庞大,为后期的维护增大成本。比如说,我们改了一个controller类,就得整个项目全部编译。
2、比如说项目的util包里封装了很多通用工具类,当前项目可以用,其他项目也可以用,如果是上面的划分模式,就得依赖项目war,这变得非常的恶心,因为在maven中配置对war的依赖远不如依赖jar那样简单明了。
其实这种划分没有遵守一个设计模式原则:“高内聚,低耦合”。虽然我们通过包名划分了层次,这很好,但还不够,因为就构建层次来说,所有东西都被耦合在一起了。因此我们需要使用Maven划分模块(module)
如下图:
artmuseum-parent为所有module的父类,打包类型为pom,只有一个pom.xml文件用于管理module;
artmuseum-common被artmuseum-parent管理,该工程用于封装工具类、常量,打包类型为jar;
artmuseum-manage同样被artmuseum-parent管理,为该项目主要module,用于管理controller、service、dao、pojo这四个module,打包类型为pom;
module之间依赖关系如下:
artmuseum-manage-controller ->
artmuseum-manage-service ->
artmuseum-manage-dao ->
artmuseum-manage-pojo ->
artmuseum-common
这种划分就解决了上面的弊端:
1、方便重用,如果需要把common包中的工具类等用到其他项目组件,只需要
把common这个module执行mvn install后,依赖生成的jar即可;
2、利于扩展和维护,修改了controller层的代码,只需要mvn install这个module即可。
基于此,今天撸了一个聚合工程出来,用到了SSM框架并实现了一个发布项目的接口(简单的入库)。
工程结构如下:
接口测试如下:
入库成功如下:
看完上述内容,你们掌握如何进行maven模块划分实践的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注亿速云行业资讯频道,感谢各位的阅读!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。