八月下半月，在上半月的基础上，根据客户的新需求在原来的审批子系统上修改完善重构，来满足新的需要。下面对工作内容逐个分析总结一下。
1.第一个工作就是要把业务数据与审批流程状态数据分离。原因有两点，一是这样设计会更加清晰，以后也便于维护。二是客户要求查询对象支持多个。（之前是一次查询一个对象，其实这里是经理搞错了，需求一直都是查多个）。 然后问题就来了，之前是一张表，现在是要分成查询表（存放查询公有信息），查询对象表（存查询对象信息）和流程信息表（存放当前审批流程结点的状态），因为之前只有一张表，所以对应的数据访问模型也只有一个叫做totalModel。然后因为自己经验不足，服务层也共用了这个totalModel, 因为换成三张表存的话对应的model也应该增加到三个。那么问题就来了，这原来的service层也依赖于这个totoalModel，所以如果要把它拆成三个model的话要修改的地方就特别多。这里主要是想以前写好的代码不用再修改，而有可以用新的三个model完成后续的开发。这里我想的是把三个model组合进totalModel里面，然后对totalModel的getter setter做相应的封装。这样之前的代码用到totalModel属性的地方就不用去修改，只是属于组合类的属性需要把值设置到组合类中然后再将组合类对象设置到totalModel里。
2.然后就是这个model的使用，我是service层和data dao层公用了同一个model。这样用的好处是方便，不用建很多概念重复的model。缺点也很明显，service层和dao层耦合在了一起，不便于维护。当初没有把两层的model分开就是觉得两层需要的model是同一个东西，没有必要分开。那么现在看来分开是必要的，原因一就是可以应对第一点总结中的表结构发生的影响，在数据访问dao层接口不变的前提下，对service层的影响是会被隔离的，反之亦然。第二点就是，数据访问层的model往往更加全面，因为会包含表中所有的字段，但是service层的model可能只是一个比较小的子集，或者是根据业务从几个表中提取出的抽象类。 所以考虑到这两点，还是不要公用model比较好。
以上两点是来自工作的教训吧。
----------------------------下面是吐槽的（有时间再补上）---------------------------------