入参等数据校验的思考

在进行真正的业务操作之前，为了确定数据都是合法可靠地，需要对数据进行检查。数据一般有以下几个来源

• 外部调用
  – 前端
  – 第三方服务
  – 另一个可信服务
• 数据库

显而易见，数据的校验越早越好，这样后面被调用的方法就不用再校验。如此看来public方法一般需要校验而private方法可以不校验。为了方便阅读，private还是可以加上annotation。

外部调用

对于外部调用时的检查又可以分为两种

外部数据本身的检查

• controller
  这个应该在controller来做掉，并且有的时候存在方法合并的问题。就是一个调用可能指向后端的两个方法。并且这个时候如果不能完美的将这个调用分为两个方法的话，使用校验框架也会比较麻烦，应为数据间存在依赖。
  如果把对可信服务的接口单独出来的话，可以减少一些调用。但是这样的问题就是面临了解对方的业务。并且把接口分为内部调用和外部调用觉得有些不够优雅，不够厉害。
• validate
  就是使用校验框架来处理，最好是隐含着通过Filter或者AOP来处理，这里面又可以分为两种
  – interface 需要dto实现validate接口，然后AOP只负责调用即可。好处是灵活
  – annotation 在字段上加上限制条件，然后AOP根据这些条件去处理。 好处是中文意思比较一致（可以根据annotation上来）

结合本地数据检查

这个应该在domain来做，应为这个多少算是业务逻辑相关。比较麻烦的也是一个外部调用对应两个domain方法的问题，这是domain的入参未必一致，可能存在转化的需要。另一个需要做转化的原因是DTO和parameter的差别还在于是否有Session的数据。

数据库

数据修复

这样处理符合上面提到的最早校验的原则。比较麻烦的是默认值的处理，就是后面新增的字段，特别是这个字段可能不是一个column而是json里的一个字段。这里涉及到新增字段是统一update来修改原有数据还是保留。

统一update

这个做法的问题是将业务逻辑从domain移动到了sql。如果都是同一个值还好多，如果有判断与计算则sql会比较麻烦。

由domain来重新处理

这样做的话就要将数据库的所有数据都过一遍。感觉动作比较大。这样做的另一个问题（或者是好处）是发消息通知其他系统做更改。

延迟处理

就是加了新的字段时并不改动数据库，而是在做业务时读出来再处理。这样的话系统更新会比较快，安全。缺点是不断积累可能为空的字段需要加上默认值处理。另外一个问题是查询的时候默认值处理再一次到了sql那里。

结论

尽可能避免一个controller根据if来调用两个domain方法的情况。通过url或者面向对象来处理成无差别。
service可以不处理入参但是service调用的domain还是要处理
新增字段的处理要及早处理，通过建新表来避免最好。如果是新增的计算得到的字段如何处理还没想清楚。