规范-编码规范总结（微信分销系统）

项目整体架构技术栈 Spring、SpringMVC、MyBatis、MySQL、JSP、OSS、定时器、微信相关接口

项目目录结构总结

只要在二个或二个以上地方用到的代码必须抽取处理，抽取工具类。

校验方式和业务代码混合在一块不方便于代码的维护。这里建议都使用hibernate-validator来做分组校验，可以提高校验的可读性和扩展性，或者使用aop做公共部分的业务做统一的校验处理。

这里的中文提示切记不要这样写，因为这里的校验提示不是在一个地方用到，提示在添加和修改会同时用到，所以切记重复使用二次或二次以上的代码要进行抽取，用常量类中统一处理。

统一提示页面，该页面用来处理所有form表单提交的同步请求（区别于一些ajax异步请求），对应ajax异步请求建议采用前端封装一个统一提示的模态框用于前端的一些参数校验和异步响应的后台提示。

controller 调用service 的insert接口，建议不要再封装一个其他的BaseModel，然后再用BaseModel的返回值处理，这种写法对应经常用这种方式的可以，但对于一些其他的陌生这种开发方式的人来说提影响开发效率的。这里建议，调用service返回的？？？待总结

切记controller中的请求路径一定要有一定的规范，这样代码即美观有方便维护，每个模块要划分明确，也便于做权限管理。

最好都生成一个package-info.java 并在这个java类中填写一定的模块介绍，方便代码的维护，这样当你10年后回来看自己的代码也不会那么迷茫了。

首先用mybatis-generator 自动生成代码速度快，但都建议生成xml代码后进行一定的调整，调整可以如下： 1. 多使用xml代码片段（表名，表列名，多条件查询） 2. update一般都是根据主键id来局部更新的，所以写一个update就可以了，用if判断一下再去更新。 3. 生成的代码中都是对参数做了jdbcType类型处理了，建议都去掉，可以提供代码的扩展信息（随便添加字段就不用担心类型写错了）

前后台交互封装成对象的方式： 1. 前台是通过ajax异步请求请求后台路径或在app接口开发的时候，建议可以采用如下正确的写法2。

2. 封装比较合适的相应参数

不管是mapper接口中还是service接口中保存和更新需要设置返回值吗？但你设置返回值的时候保存成功必然返回值为1，但保持失败必定是抛出jdbc操作数据库异常，所以我这里建议使用不设置返回值且不用返回值来处理业务逻辑，成功代码执行完成，失败捕获异常返回给前端。需要证实

在同一个service方法中涉及到二个或二个以上更改数据操作的方法中必须设置回滚事务操作，不然会造成数据的不一致。当有一个select和一个insert的时候可以不做回滚处理，因为不会影响数据的一致性。

在页面的分模块管理也尽量常用统一的命名和和controller请求路径的机制命名，方便代码的定位和编写代码的效率。比如listView，可以在多个模块中来回拷贝，改个标题名可以用了。还有就是对应一些如：页面顶部或底部div尽量都抽取出来，做代码的复用，这样就不用再多个页面中来回改了，改一个页面就可用，减少bug数量，提高效率。

在每个页面的公共头部分加入公共代码basePath这样就能在多个页面中取这个值用于不同页面的请求url了。

定义统一异常处理，针对不同的异常来统一处理，这个时候在service就可以自定义异常类来统一处理异常，这个时候在service操作异常后就直接抛出自定义的异常就行，在controller也不要对异常进行处理了。

尽量在数据库中不要用int来存身份和角色相关的属性，这样没有文档谁都看不懂，使用varchar就行，就是多占点空间而已，但对于代码的可读性和可维护性提高不少，即使你数据库中使用的时候int来存储，切记在代码中也要使用常量属性来定义类型，并写上注释。

切记一切上传功能（oss）都要抽取工具类，且抽取方式要合理，不要把一切代码都写在service中，这样代码可读性不高。

在上传oss功能中，当上传的时候（先上传，然后再把上传后的url插入到数据库中），当在插入数据库的时候失败切记一定要删除之前上传的图片，不然后来的oss文件根本没法维护。还有就是上面的那个问题，insert失败后是直接抛出异常还是返回0，直接抛出异常下面的代码就是永远都不会走的代码就没有任何意义了。

service 可以使用void 不用自己再封装baseModel 了，然后一些业务异常就抛出自定义的异常，如果是操作过程中没有抛出任何异常，就在controller直接业务操作成功。

对应controller中的多个查询因为不会涉及到事物一致性，所有就直接查询实体存放到model中就行。