??? 再次談起三層架構來，初識三層時的那種向往，那種青澀，已經不見了蹤影，取而代之的是對分層的感慨。 ? 分層，三層也好，七層也罷，都是將頁面顯示、業務邏輯控制、數據訪問進行解耦。還有MVC和設計模式也是這樣。只分UI,BLL,DAL這三層，只是實現了基本的解耦，但是耦合性還是很高的，尤其是對于中型及以上的系統來說，簡單的三層并不能滿足其需求。DAL提取出DBHelper，BLL中提取出Facade層，還有各層之間其實都應該加上接口。這樣系統的靈活性才會大大提高。 ? 對于B層的劃分，有人說按數據表走，一個表一個類；有人說按窗體走，一個窗體一個類(PS:我這里是重構，有原系統做參考，如果是開發一個新系統，則沒有這種說法)；有人說按用例走，一個用例一個類。合作開發完以后，我好好分析了一下這三者。第一種方法，B層的類會相對少一些，維護工作會比較輕松，不過假如增加一個功能，那么就得相應的修改B層的類，不滿足開閉原則。第二種方法，局限性更大。只要修改窗體，就得修改類。這樣給人的感覺，B層依賴于UI層。但是分層應該是上層依賴于下層。第三種方法，滿足開閉原則，添加功能，直接添加一個類即可。但是不足的是B層中類太多了。分析之后。我覺得應該改善第三種方法，在B層包中，為每個表添加一個子包，然后對應B層的操作放到對應子包中。這樣就不會太亂了。添加功能時，直接在對應的子包中添加類。一個用例一個類。滿足了開閉原則和單一職責原則。 ? 對于Facade層如何劃分，暫時沒有確定的想法。有2種觀點：一是將有關系的類，相近的類放到一個外觀類。另一種觀點按UI層來劃分。不過感覺第一種觀點稍微科學一點。暫時沒有更好的想法。 ? 在個人版和合作版開發完后，感覺接口挺重要的，開發接口可以大大增加系統的靈活性。而且，每一層只要針對于接口進行編程即可。不用考慮下一層的具體實現。下一層如何更改都無關緊要，只要接口不變，那么系統運行無阻礙。在開發前期，先開發接口，這樣上層接口在編程時，調用下層會很容易，且不易出錯。調試的時候也很方便。