笔者团队以前后台都是基于.Net和.NetCore, 今年转Java了，不是.Net相关技术不好，而是在中小城市相关开发人员缺乏，Java相对来说开发人员要丰富很多。
后台有必要重新搭建一个内部的开发框架，由于没有历史积累，直接使用SpringBoot作为基础框架，在此之上再做一个封装。
分享出来给大家参考，此框架适应于中小企业Java实现的WebAPI项目（前后端分离）。大家可以直接使用，但是最好还是理解并修改成适用自己团队的框架。
1.基本结构
image.png
如上图，我们的框架包含很多库，其中
d1.framework.webapi和d1.framework.cache是所有webapi项目都必须依赖的，其它的库是看需求选择依赖的。下面列出所有库的基本功能：
-
d1.framework.webapi: 业务项目依赖的基本库，包含springboot相关很多功能的封装，比如Application、Entity、Service、Controller等基类，还有swagger、跨域，权限统一认证，日志相关等等，后面单独说明。 -
d1.framework.cache: 缓存相关的库，因为d1.framework.webapi依赖这个库，所以所有业务项目也都依赖它，一个接口外加ehcache和redis的实现，实际业务项目中选择一种就可以。 -
d1.framework.storage: 不是必须依赖的库，一个接口外加本地文件存储和七牛云存储的实现。 -
d1.framework.util:不是必须依赖的库，实现一系列工具类，是在业务项目开发过程中逐渐积累的一些和业务无关的静态方法。 -
d1.framework.push:不是必须依赖的库，实现极光推送，这个是我们团队比较常用的app推送第三方库的封装。 -
d1.framework.sms:不是必须依赖的库，一个接口外加二种第三方的短信封装，主要用于注册等短信验证。 -
d1.framework.weixin:不是必须依赖的库，微信小程序、公众号、app等开发平台相关封装。 -
d1.framework.ocr: 不是必须依赖的库，封装了阿里的二个图形识别服务，也是实际业务项目用到了后封装的。 -
d1.framework.mqttclient:不是必须依赖的库，是对mqtt协议的实现，也是对一个开源库的封装。
2. 基本说明
- springboot已经非常方便了，但是还是有必要把一些重复的不变的功能封装成框架，开发框架和开发业务应该分开。
- 框架里有一些我们团队特有的约定，并不一定适合所有人的习惯。
- 所有业务项目使用gradle工具构建，主要是觉得gradle比maven更简洁。
- 框架所有项目都上传到我们内部的Nexus
搭建的maven库，搭建的方法可以参考我以前发的贴。 业务项目通过gradle来配置依赖：
repositories {
mavenCentral()
maven{ url 'http://你的nexus库地址/repository/d1-java/'}
}
- 除
d1.framework.webapi库强制依赖springboot以外，其它库都没有依赖springboot，这样其它库也可以很方便用于非springboot的业务项目 - 大部分库都是先定义接口，再对这个接口进行实现，通常有好几种实现。
- 很多第三方库已经很简单了，但是还是有必要做一次封装，主要还是第三方库功能很多，但是我们通常用到的很少，而且有很多缺省用法，封装后使用更简单，也能让第三方库版本变化后对现有业务项目也没影响。
- 每个库项目都由一个springboot业务项目作为测试库的入口以及一个库真正实现的module，这个module修改完后build成jar包并推送到nexus服务上。
- 所有业务项目都是在IDEA下开发，没有使用Eclipse。
- 框架是在业务项目不断的开发中逐渐积累和完善的，功能会越来越多，bug会越来越少。
3. 源码
源码都上传到github,下载后要跑起来还需修改：
- 搭建自己的nexus服务，或者改造业务项目生成jar包，然后使用本地依赖方式。
- 所有第三方对应的密钥信息都已经修改成一些随便的数字，确保安全性，
- 源码里除了框架库代码，还有一个
d1project项目是用于使用框架的一个webapi模板项目。如果新建一个业务项目可以通过拷贝这个项目作为基础。
本文是第一部分，第二部分主要是对
d1.framework.webapi的详细介绍。
跳转到第二部分
