本文源码:GitHub·点这里 || GitEE·点这里
一、分层策略
MVC模式与代码分层策略,MVC全名是ModelViewController即模型-视图-控制器,作为一种软件设计榜样,用一种业务逻辑、数据、界面显示拆散的办法组织代码,将业务逻辑汇集到一个部件外面,在改良和个性化定制界面及用户交互的同时,不须要从新编写业务逻辑,这是一种开发模式,但并不是理论开发中代码的分层模式,通常SSM框架的后端代码分层如下:
- controller管制层:定义服务端接口,入参出参,和一些入参校验;
- service业务服务层:组装业务逻辑,业务校验,构建管制层须要的参数模型;
- dao数据交互层:提供服务层须要的数据查询方法,解决数据交互条件相干的逻辑;
- mapper长久层:基于mybatis框架须要的原生反对,目前很罕用的长久层组件;
二、管制层
1、Rest接口格调
基于资源拜访和解决的逻辑,应用不同格调的注解。例如资源新增,更新,查问,删除。
/** * 新增 */@PostMapping("/insert")public Integer insert (@RequestBody BaseInfo baseInfo){ return baseInfoService.insert(baseInfo);}/** * 更新 */@PutMapping("/update/{id}")public String update(@PathVariable(value = "id") Integer id, @RequestBody BaseInfo baseInfo) { if (id<1){ return "error"; } baseInfo.setId(id); return "update="+baseInfoService.update(baseInfo);}/** * 主键查问 */@GetMapping("/detail/{id}")public InfoModel detail(@PathVariable(value = "id") Integer id) { return baseInfoService.detail(id) ;}/** * 主键删除 */@DeleteMapping("/delete/{id}")public String delete(@PathVariable(value = "id") Integer id) { baseInfoService.delete(id) ; return "SUS" ;}
2、接口复用度
不倡议接口高度复用,例如增删改查都各自对接接口即可,根本准则,不同的客户端端操作,对于独立的接口。
/** * 列表加载 */@GetMapping("/list")public List<BaseInfo> list() { return baseInfoService.list(new BaseInfoExample()) ;}/** * 列表搜寻 */@PostMapping("/search")public List<BaseInfo> search (@RequestParam("userName") String userName, @RequestParam("phone") String phone) { return baseInfoService.search(userName,phone) ;}
例如常见的list接口,list通常都有会按条件加载的search机制,而且搜寻的判断条件很简单,倡议分为两个接口,从理论思考,大部分场景下都是只应用list接口,很少应用search搜寻。
3、入参出参
校验客户端必须条件,例如某某条件必填必选等,如果有问题,疾速阻断申请链路,做到程序入口管制层拦挡返回。
@PutMapping("/update/{id}")public String update(@PathVariable(value = "id") Integer id, @RequestBody BaseInfo baseInfo) { if (id<1){ return "error"; } baseInfo.setId(id); return "update="+baseInfoService.update(baseInfo);}
参数在三个以下,能够间接排列入参,参数在三个或三个以上能够应用实体类对立封装。
@PostMapping("/search")public List<BaseInfo> search (@RequestParam("userName") String userName, @RequestParam("phone") String phone) { return baseInfoService.search(userName,phone) ;}
4、参数解决
出参格局解决度根本准则,服务器作为公共资源,防止非必要操作,例如客户端可自行判断返回值是否为空,null等,或者一些常见格局解决,利用客户端适当分担服务器压力。
三、业务服务层
1、业务校验
例如传入订单号,通过数据库层查问,没有订单数据,这里称为业务性质的异样,代码自身没有问题,然而业务逻辑无奈失常执行。
public InfoModel detail(Integer id){ BaseInfo baseInfo = baseInfoDao.selectByPrimaryKey(id) ; if (baseInfo != null){ DetailInfoEntity detailInfoEntity = detailInfoDao.getById(id); if (detailInfoEntity == null){ LOG.info("id="+id+"数据缺失 DetailInfo"); } return buildModel(baseInfo,detailInfoEntity) ; } LOG.info("id="+id+"数据齐全缺失"); return null ;}
2、组装业务逻辑
通常状况下服务层作为逻辑做简单的一块,用来拼接业务外围步骤,能够通过业务逻辑断定,一步一步执行程序,防止在程序入口做大量可能用到的对象创立和需要数据查问。
public int insert (BaseInfo record){ record.setCreateTime(new Date()); int insertFlag = baseInfoDao.insert(record); if (insertFlag > 0){ DetailInfoEntity detailInfoEntity = new DetailInfoEntity(); detailInfoEntity.setUserId(record.getId()); detailInfoEntity.setCreateTime(record.getCreateTime()); if(detailInfoDao.save(detailInfoEntity)){ return insertFlag ; } } return insertFlag;}
3、数据模型构建
通常状况业务层是偏简单的,如果想关疾速了解业务层,能够对简单的业务办法,在提供一个返参构建的办法,用来解决服务层要向管制层回传的参数,这样能够让重度的服务层办法变的清晰。
private InfoModel buildModel (BaseInfo baseInfo,DetailInfoEntity detailInfo){ InfoModel infoModel = new InfoModel() ; infoModel.setBaseInfo(baseInfo); infoModel.setDetailInfoEntity(detailInfo); return infoModel ;}
四、数据交互层
1、逆向工程
这里以应用mybatis框架或者mybatis-plus框架作为参考。如果是mybatis框架,倡议逆向工程的模板代码不做自定义的批改,如果须要自定义办法,在mapper和xml层面再自定义一个扩大文件,用来寄存自定义的办法和SQL逻辑,这样防止表构造变动大引发的强烈不适。
当然当初大部分都会mybatis-plus作为长久层组件,能够防止上述问题。
2、数据交互
针对业务层的须要,提供相应的数据查询方法,只解决与数据库交互的逻辑,避免出现业务逻辑,尤其在分布式架构下,不同服务的数据查问和组装,不应该呈现在该层。
public interface BaseInfoDao { int insert(BaseInfo record); List<BaseInfo> selectByExample(BaseInfoExample example); int updateByPrimaryKey(BaseInfo record); BaseInfo selectByPrimaryKey(Integer id); int deleteByPrimaryKey(Integer id); BaseInfo getById (Integer id) ;}
五、源代码地址
GitHub·地址https://github.com/cicadasmile/data-manage-parentGitEE·地址https://gitee.com/cicadasmile/data-manage-parent
举荐浏览:编程体系整顿
序号 | 项目名称 | GitHub地址 | GitEE地址 | 举荐指数 |
---|---|---|---|---|
01 | Java形容设计模式,算法,数据结构 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
02 | Java根底、并发、面向对象、Web开发 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆ |
03 | SpringCloud微服务根底组件案例详解 | GitHub·点这里 | GitEE·点这里 | ☆☆☆ |
04 | SpringCloud微服务架构实战综合案例 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
05 | SpringBoot框架根底利用入门到进阶 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆ |
06 | SpringBoot框架整合开发罕用中间件 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
07 | 数据管理、分布式、架构设计根底案例 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |
08 | 大数据系列、存储、组件、计算等框架 | GitHub·点这里 | GitEE·点这里 | ☆☆☆☆☆ |