對於一個剛入手編程的菜鳥來說，都想編寫一個可讀，可維護，性能高的程序，我也如此，在面臨Boss的項目時候，拿起來立馬就開始編寫主要功能，然後環形拓展，類似快速開發模型，慢慢的就發現在修改某些功能時候是如此的繁瑣，肯定的說不是一個好的程序員；當你拿到一個Project，你需要的是設計而非噼噼啪啪敲代碼，設計好的架構是至關重要滴，在此勸誡每一位新手。
那麼入如何能有效的設計出來程序架構呢？即“高內聚，低耦合”的程序模塊呢？我弱弱的在此推薦三層架構，其來源於MVC，核心是保持三層之間的相互獨立，在對其功能修改時，可儘量保持三層架構不變，避免了全盤否定，從頭再來；換言之，即在修改某些功能時候知道從哪入手，不必要挨個尋找，修改的地方是必要的，不是嘗試，這改改那改改，從而減少修改量。從開始學習到現在，不得不說，修改局部代碼對整體的變動影響還是蠻大的，層次越多，修改的地方越多，也就是說Project越複雜，你需要的設計越複雜，因此帶來邏輯和接口複雜性的增加。
So,what's 三層架構(3-Tier Architecture) 咧？查閱相關資料，統一回答如下：
三層架構包括：
1. 數據訪問層（Data Access Layer, DAL）：它的各個函數完成的僅僅是對數據文件的操作，不管其他操作；然後負責將底層數據傳送到業務邏輯層
2. 業務邏輯層（Business Logic Layer， BLL）：處理數據訪問層傳送的數據，主要負責對數據層的操作，把一些數據層的操作進行組合，並實現業務邏輯
3. 表示層（User Interface， UI）：不處理任何業務，負責顯示與實時更新，即接受用戶的請求，以及數據的返回，爲客戶端提供訪問。
其三之間的關係如下圖：
在百度百科裏說設計三層架構需要幾個原則，在此借用一下：
⒈ 最關鍵的，UI層只能作爲一個外殼，不能包含任何業務邏輯(BizLogic)的處理過程
⒉ 設計時應該從BLL出發，而不是UI出發. BLL層在API上應該實現所有BizLogic，以面向對象的方式
⒊ 不管數據層是一個簡單的SqlHelper也好，還是帶有Mapping過的Classes也好，應該在一定的抽象程度上做到系統無關
⒋ 不管使用COM+(Enterprise Service），還是Remoting，還是WebService之類的遠程對象技術，不管部署的時候是不是真的分別部署到不同的服務器上，最起碼在設計的時候要做這樣的考慮，更遠的，還得考慮多臺服務器通過負載均衡作集羣。
因此在面對Project時，仔細想想是否需要設計成三層架構，不要照搬，切記，三層架構是面對複雜的項目提出的，遇到小的項目就可以簡單面對了。
相關代碼在後續的博客中加入，請各位大神指教。
轉載請標明出處http://blog.csdn.net/jasonhds/版權所有，翻版必究~謝謝合作！