[随记]被区分对待Manager和Service层头疼了两天

本打算在架构整理时使用类似Struts的DispathAction的功能，使用一个参数转发来决定调用Service的方法。因为DispathAction在struts的意图就是减少出现的类。但是想来想去，这样的话就必须多实现一个Manager层了，每一个Service都必须通过Manager来调用，多了很多近乎“光秃秃”代码的Proxy类，仅做一下转发的Manger。如果以后维护起来，那么页面修改后，Manager也同时需要修改，增加Manger层徒增维护的负担。最后决定不使用Manager层，既然是转发，Struts、DWR或XFIRE已经就是Dispatchor了，何必自己再去Dispatch一下呢？把简单搞复杂，真觉得自己有点为架构而架构了。弄成学究了可麻烦

当前定义Manager就是为了达到一个业务对应一个页面，而每个业务会有很多的操作方法。因此从业务的逻辑上说一组操作可以为一个Manager。但是Manager逻辑的修改，除了页面变动外，不想再额外的去维护仅保持也页面功能点一致的Java Proxy。因此放弃Manager层的想法。还是直接通过应用层代理调用Service方便。