本打算在架構整理時使用類似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方便。