代码规范

先配置处理异常的类，然后在分析源码 mvc统一处理异常的实现常见的异常如下，基本都是参数校验的异常。参数校验需要配合jsr303的注解校验哦。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167@Slf4j@RestControllerAdvice@Conditi ...

mybatisPlus大大的提高了我们开发的速度。因为不需要关心sql。建立好的对象通过mybatisPlus语法糖来拼接sql。但是坏处是语法糖不好统一维护。到处都是语法糖。 所以我们规定建立一层Dao，dao层负责统一管理sql。因为要去除xml里面的sql。写sql容易出问题（字符串容易写错，不同数据库还需要关心不同的特性）建议Dao统一继承此BaseDao 一个表对应一个实体、一个mapper，一个DaoDao继承BaseDao，需要实体继承BaseDomain,mapper继承CustomBaseMapper如果实体不继承baseDomain，mapper不继承CustomBaseMapper，则dao也无法继承BaseDao 如何有效(强制)的避免以下相同拼接的sql出现在多处？例如以下的sql拼接语法糖 123456789101112131415161718192021222324252627public DemoService { @Autowired DemoDao demoDao; public void ...

常见的代码分层图 分层很明确，先说缺点 service层可以依赖多个dao层一个表肯定对应一个dao。如果一个service直接操作多张表(dao)也没问题，但是有可能所有表的操作都封闭在一个service中。 如果后期维护某一张表的时候你就得需要屡下所有调用此表的service，花费时间不说，还有可能漏掉。 如果对其中一个表进行别的业务复用的话，则需要把代码抽离出来，并且有可能开发人员不抽离，而是直接copy粘贴，导致代码原来越乱。 所以建议一个表对应一个dao和一个service，其中service只能操作自己的表(dao)。要是操作其他的表只能依赖其对应的service 上图没有明确表明哪些是可以互相依赖(service依赖其他service，dao可以依赖其他dao...)，哪些不可以互相依赖。所以我们认为都是可以相互依赖的。互相依赖比较混乱。 dao专门负责管理sql，如果对一个实体的curd还涉及到另外其他的实体curd。那么这就显然属于业务范畴了，应该放在service。所以在dao这一层。我们不能让他操作多张表(不能有互相依赖) 没有强制的依赖校验。如果 ...