搭建一个系统,首先第一步就是要组织目录结构,目录结构组织的好坏,直接关系到以后的开发和维护,一个清晰明了的目录结构,可以让开发者很容易知道某些功能或方法应该放到什么位置。之前参与一个项目的开发,目录结构很乱,想定义常量类,或者服务工具类完全不知道应该放在什么位置,导致每个人都随便放,随着项目变大,越来越乱。
还是以商品管理系统为例,来说下目录结构组织
项目组织结构
说明
1.1. 根项目:shopmanage-project
1.2. 在根项目下面,新建shpm-api-project(存放对外提供的服务接口),shpm-config-project(存放整个项目的公共配置),shpm-utils-project(存放整个项目的公共工具类),shpm-emall-project(对应api接口中某个服务集的具体实现)。
1.3. 由于项目使用Gradle构建,所以需要在根项目下新建build.gradle和settings.gradle。
创建完项目后的目录:
build.gradle
该文件为Gradle项目的必须文件,内容如下:
//针对所有项目设置
allprojects{
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'maven-publish' //maven发布插件
compileJava.dependsOn clean
//设置编译源码JDK版本
sourceCompatibility = 1.7
//设置gradle缓存依赖超时时间,0则表示每次获取最新的。
configurations.all {
resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}
}
//针对子项目设置
subprojects{
//设置编码
[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'
//设置获取依赖包的仓库地址
repositories {
//自己的nexus私服地址
maven{ url "http://198.1.249.149:8081/nexus/content/groups/public/" }
mavenCentral()
}
//设置源码和资源文件,如果不设置gradle默认为:src/main/java,src/main/resources,src/test/java,src/test/resources
sourceSets {
main {
java {
srcDirs = ['src/main/java','src/main/implapi', 'src/main/generate','src/main/cache']}
resources {
srcDirs = ['src/main/resources']
}
}
}
dependencies{
/*test*/
compile 'junit:junit:4.11'
/*fastjson*/
compile "com.alibaba:fastjson:1.1.39"
}
}
//设置emall项目对其他项目的依赖
["shpm-emall-project"].each{core_project ->
project(core_project){
dependencies {
compile project(":shpm-utils-project")
compile project(":shpm-config-project")
compile project(":shpm-api-project")
}
}
}
settings.gradle
多项目时需要设置,设置了该内容后,导入eclipse中会将根项目下的子项目提取出来,和根项目显示在同一级,注意:只是在eclipse中显示为同一级了,其实还是在根项目下的。
include "shpm-config-project","shpm-api-project","shpm-emall-project","shpm-utils-project"
做完上述工作就可以使用eclipse的Import导入项目了。eclipse导入Gradle项目
扩展
由于商品管理系统功能简单,只需要一个数据库,故将所有实现放到了同一个项目中,即shpm-emall-project中,如果项目大了,可以根据服务的聚集性,单独抽取成多个数据库,每个数据库对应一个项目,项目和项目之间保证低耦合,通过Rest调用,这也就是微服务架构了。
例如我们现在增加订单中心,客户中心等,每个都是一个独立的服务,则可以在api接口中新建IOrderManageSV,和ICustommManageSV,而每个接口对应一个独立的实现项目,shpm-order-project,shpm-custom-project,调整后如下图。
包组织结构
接口项目中包定义
api项目中均为对外提供的接口,最好严格规定入参和出参,最好全部封装成对象,及时没有入参或出参也最好封装成对象,且他们均可以继承一个基类,例如xxxRequest继承BaseRequest,xxxResponse继承BaseResponse,这样做的好处是可以在基类中添加一些公共代码,以后增加拦截器等也可以统一设置。
以商品管理系统为例,在emall下面按照具体功能划分,pmloginauth包含登陆的相关接口,productmanage包含对商品操作的相关接口。每个具体包下,细分为interfaces和param。
具体项目中包定义
具体实现项目中主要是为了实现服务接口中定义的服务方法,业务逻辑等几乎在此项目中实现,因此功能较多,包定义的清晰明了,对写代码以及以后查找代码有相当的好处。
说明
- src/main/api:对shpm-api-project中接口的实现
- src/main/generate:保存自动生成的文件,例如Mybatis自动生成的dao,bean等。
- src/main/cache:保存缓存的相关操作。
- src/main/java:保存具体的业务逻辑。
- src/main/resources:该项目的资源。
事物设置在src/main/java/下的busi上,该包为所有业务的总入库,src/main/api的具体实现均是调用busi中相关代码实现。严格规定包之间分层的好处:只要api项目中的接口不变,后台我们自己内部重构不影响外围系统的调用,不用担心是否有其他服务调用我们,在保证api接口不变的前提下,我们可以大胆重构。