版本控制与过滤器设计

    2013年的第一篇博客，祝大家新年快乐。有段时间没维护博客了，太懒了，也不知道该写些什么，写学习心得感觉不如看书来的直接，写技术应用吧又没那么多货。最近不是很忙，前天抽空把过滤部分的代码剥离了个原型出来，谈不上复杂高深，权当抛砖引玉，大家有好的想法欢迎交流学习。
    之前我博客中谈到关于过滤器与缓存，需要指出一点我们所需要过滤掉的数据并非是毫无用处的脏数据，而是在某些特定环境下不合适的数据。例如DB内存放了一个榜单A,对与某个应用的不同版本v1、v2、v3能处理的分别是A的一个子集B、C、D。应对这种情况，有几种处理方式：
    第一种，在分别根据版本1、2、3在DAO层维护三份数据，也即需要不同的查询指令（可以认为这也是一种过滤），毫无疑问这种方案是成立的，然而问题是如果每个版本应用都需要维护不同的数据接口维护以及代码的整洁度都会受到影响；
    第二种，在DB为每个版本维护不同的数据源，即在数据创建时为不同版本创建合适的数据列表，这种设计在最初情况下可能是生效的，可是版本迭代以及数据更新将会给数据维护和运营造成巨大压力；
    第三种，便是我采用的过滤器方案。这一方案是也是建立在方案一和方案二至上的，我使用sql来完成对数据的筛选（查询满足某系条件的数据集合），对不同端无法公用的数据当然需要分别维护，在此基础上我引入了过滤器来解决客户端版本迭代功能差异对数据的不同要求。假设DAO层取出数据集合A，在Facade层通过对版本的识别，对于v1我过滤掉A-B部分，对于v2过滤掉A-C(缓存可以施加在过滤完成之后的数据至上)。这种方式的好处是：1.为版本向后兼容提供了便利，倘若数据集合A在不断扩大，响应的v1版本需要过滤的条件也增多，只需要新增入新的过滤器便能够完成这一工作；2.为代码复用提供可能性，对与v1、v2可能存在共有的过滤条件，针对该条件设计的过滤器便可以进行复用。
    说完过滤器，再简单谈谈版本控制，版本控制最重要的是要做到兼容，向前的兼容自然不必说，未来的需求永远无法预知所以向后的兼容也很重要。我们采用了功能码来区分每个不同版本对数据的要求差异，为什么不用版本号区分？如果采用版本号，意味着需要给每个版本建立分支，维护难度太大。例如v1支持功能b能处理的数据为B，v2支持功能b、c能处理的数据为C(C包含B)，v3支持功能b、c、d能处理的数据为A(A包含C)，对于v1、v2、v3我分别设定了一个功能码1、11、111，左起每一位1分别表示支持bcd功能，v1的码值为1支持功能b那么就需要过滤掉A-C、C-B这部分数据，对于v2需要过滤掉A-C，v3支持全量的数据A无需过滤。当数据集A扩充至X，v1的码值是不改变的1，支持数据也为B，需要过滤的数据则为X-A、A-C、C-B，即新增了过滤X-A数据的filter，而这个filter对于版本v2、v3同样适用，这就完成了向后兼容以及代码复用的设计需求。
     附件里是我剥出来的代码，没有把根据功能码进行版本控制这部分功能放在里面（这个实现不困难，大家有兴趣可以自己试试）。有不足指出欢迎大家指出讨论。