现在系统中有很多如下流程，1：上传数据，上传数据的时候要做校验，2：保存数据 3 查询列表 等等简单操作
现在有10几种这样的数据 都有这样的流程，
相同的地方：所有的数据流程，操作一样
不同点：数据模型不同，数据和数据表1对1，
系统采用action-app-biz-dao四层，
现在有如下问题请教：
1种方式：对于这种数据是用 1个action对1个app，然后再app中通过业务类型找对应的biz操作，由于不同数据的校验都不同，
在app中注入一个校验接口，每个数据都实现一个校验类，是否是策略模式？
2种方式：app为抽象类，在app层中的上传数据方法中，加入一个抽象的校验方法，然后每个子类都继承这个app抽象类，实现校验接口，这种貌似模板模式？
这两种哪种设计好些？考虑可扩展性，比如查询列表或者保存数据中 业务数据有可能要做转换？这样对于方式1 要定义一个新的转换接口？对于方式2 就要定义一个抽象方法，子类再实现。。
应该使用Proxy模式或Decorator模式。这两个都是在原对象前加上一些新的东西，你是希望在数据之前加上数据校验功能，属于结构模式范畴。
bang老大的意思是在action app层之间加个proxy层，代理类再调用不同的校验类？我感觉直接在app层里面 注入校验类 通过不同业务类型取得不同校验类，代码还简洁一些吧？
里外都一样，都是代理意思，不同校验类选择属于策略，所以是Proxy+策略。策略是结构架构模式，策略是小模式，两者配合。
在banq老大的建议基础上，考虑到可能进行多种校验，提供一种参考：可以采用Proxy模式+策略模式+职责链模式一起来解决。
原因：假设有C1,C2,C3,C4种校验，假设存在的数据有D1,D2,D3,D4种，考虑一下D1数据需要进行C1,C3校验，D2数据需要进行C2,C3校验，D3数据需要进行C1,C4校验，D4数据需要进行C1,C2,C3校验。
如果保存数据在校验之后马上进行，也可以把保存数据作为职责链中的一个职责，放在链中一起操作。