系統的分層設計帶來的好處是顯而易見的，由於層間鬆散的耦合關係，使得我們可以專注於本層的設計，而不必關心其他層的設計，也不必擔心自己的設計會影響其它層，對提高軟件質量大有裨益。而且分層設計使得程序結構清晰，升級和維護都變得十分容易，更改層的具體實現代碼，只要層接口保持穩定，其他層可以不必修改。即使層的接口發生變化，也隻影響上層和下層，修改工作量小而且錯誤可以控制，不會帶來意外的風險。系統的分層設計，估計沒幾個程序員不知道，但是在一些大大小小的項目裏，能真正做到的，恐怕不多！
有些程序員或系統設計人員認爲對於一個小項目，沒有必要這麼做，但我認爲除非你對這個項目有非常的瞭解，確保它不會在以後增加新的功能，你或許勉強可以這樣做，但這種情況很難保證，現在的應用系統越來越複雜，我們一定要做好應付各種變化的準備。在實踐中，很多的系統都用到了分層的設計，然而在遇到一個需求的變更時，設計的脆弱仍然不能完成這個變更的需求，我們以常見的三層結構來分析一下：
1、UI層：我說的這個UI層可能包含了很多的概念，除了大家都知道的window form和web form，它還包含了那些可能沒有用戶界面的用戶接口，像window service，web service以及.Net remoting service等的入口，它們都可以看作UI層，而UI層應該只和業務邏輯層發生關係。有些系統儘管劃分了層次，但卻將部分的業務邏輯放在UI層，這就增加了UI層和業務邏輯層的耦合度，不利於UI層的增加或變換，因爲如果需要再增加另外的一個UI層，而新增加的層中又包含了原有UI層的部分功能，這時新的UI層不得不再一次實現同樣的功能，如果已實現的功能不符合要求，需要修改時，又不得不在已實現了的多個UI層中進行改動，這樣不但增加了工作量，而且增加了出錯的可能性。
2、業務邏輯層：所有的業務邏輯處理的集中地，它爲UI層提供服務。比如一個購物系統，當客戶下了訂單時，一般應該做這些事情：1、檢查提交的數據的合法性；2、驗證客戶信息；3、檢查商品信息，比如商品是否存在，是否有足夠的庫存等；4、提交訂單。這四步對於UI層來講是透明的，就是說UI層只調用業務邏輯層的一個相應的方法，而不是親自完成這四步功能，因爲這四個步驟實現了一個完整的業務邏輯，它們不可以分開。如果需要公開一個Web Service，供客戶提交訂單，Web Service的實現也只是簡單的調用業務邏輯層的一個相應的方法。
3、數據（庫）層：這一層才真正的實現了數據的存取，它爲業務邏輯層提供服務。在這一層上不需要關注業務邏輯，只是存取數據。對於確定只用一種數據存儲方式來講，這些就足夠了。但在一個分佈式的系統中，這種簡單的實現是不夠的，因供存取數據的不一定來自數據庫，也可能來自其他數據文件，比如XML、Excel等，不同的數據庫之間也有很大的差異，這些異構的數據對業務邏輯層來講都是透明的，業務邏輯層沒必要了解數據存取的細節。那麼如何才能實現這種結構？通常的辦法是爲數據（庫）層提供一個接口，業務邏輯層只是調用接口所約定的方法，這樣通過接口就可以實現很多異構數據的存取了。
如果能嚴格的區分這三個層次的功能，那麼設計的系統將大大降低了層之間的耦合度，非常利於擴展和維護，而且還很容易分配更爲合適的人工作在不同的層，增加了人員的利用率，好讓他們發揮自己的特長。
在這兒還需要提醒的一點是，如果你所用的數據庫系統支持存儲過程或者類似的功能，就一定要用存儲過程而不是將SQL語句嵌入到程序中（嵌入的SQL語句增加了系統擴展和維護的難度），大家都知道使用存儲過程有以下優點：
存儲過程已在服務器註冊 存儲過程具有安全特性（例如權限）和所有權鏈接，以及可以附加到它們的證書
用戶可以被授予權限來執行存儲過程而不必直接對存儲過程中引用的對象具有權限。 存儲過程可以強制應用程序的安全性
參數化存儲過程有助於保護應用程序不受 SQL Injection 攻擊。有關詳細信息，請參閱 SQL Injection。 存儲過程允許模塊化程序設計
存儲過程一旦創建，以後即可在程序中調用任意多次。這可以改進應用程序的可維護性，並允許應用程序統一訪問數據庫。 存儲過程是命名代碼，允許延遲綁定
這提供了一個用於簡單代碼演變的間接級別。 存儲過程可以減少網絡通信流量
一個需要數百行 Transact-SQL 代碼的操作可以通過一條執行過程代碼的語句來執行，而不需要在網絡中發送數百行代碼。
除了這些優點外，還有一個優點：可以讓一些更爲專業的數據庫人員去優化SQL語句（如果SQL語句嵌入在程序中就會比較困難，首先專業的數據庫人員並不一定是專業的程序員；其次SQL語句很多都是拼接的），現在很多的程序員並不都是專業的數據庫人員，對於大型的系統，我想更有這個必要。