從一開始接觸asp.net到現在算來也有幾個年頭了，剛開始學C#的時候，壓根不知道分層的概念，后來有了一些了解之后，發現大家都在談分層，但因為當時沒有做過什么項目，看到別人對分層的討論總是知之然而不知其所以然。后來自己嘗試用分層做了一個企業網站的項目，由於項目並不大，並且所有的前后台代碼均為本人獨自完成，老實說，並沒有感覺到分層的好處。
最近幾年的.net項目開發中，大部分也都是一個人在負責分層開發中的多種角色（數據庫訪問、業務編輯處理、前台表現及JS、JQUERY、AJAX等），另外由於大部分都是一些不太復雜企業網站項目，所以一直沒有分層。比如開始一個新的項目，如果其他項目已經實現了該功能，則直接把文件copy過來，表名一改就可以用了。對於有類似功能但不完全對應上的，拿過來稍加修改也OK了。除非一點復用可能也沒有的功能模塊，才可能去開發。這樣經過幾年積累，我可以毫不誇張的說，一般的企業網站，利用手頭的代碼，有個一兩個小時絕對能夠搞定，從這點來說，我個人並沒有覺得分層有什么太多的好處，因為如果一開始就采用分層開發，一方面分層開發本來在層之間傳遞數據的效果相對直接在aspx.cs中訪問數據庫而言，我認為肯定是慢的。另一方面，如果涉及到小的字段修改，如果采用分層開發，那么我就要把涉及到的每個層都修改一遍，而實際對於小項目而言，如果不分層的話，往往某個字段只需修改兩處即可。（前台一次，后台一次）
那么，分層究竟有沒有好處呢，網上對分層的討論始終也沒有停止過，優勢劣勢各有，大家各執一詞。從我個人而言，雖然實際應用中分層的時候並不多，但我並不否定分層。最近要開始一個大項目，也在網上查到了好多關於分層的資料。對於分層的好處，我覺得主要體現在以下幾個方面：利於團隊開發、團中的各個成員職責分工明確，各司其職即可，另外有利於系統以后的擴展，如BS轉CS，SQLSERVER轉ORICAL等，至於后期的容易維護，目前還沒有太深的體會。
綜上所述，我認為小項目沒有必要分層，小項目的分層說俗一點，完全是脫了褲子放屁，找費事。小項目做完了就是做完了，做為客戶來說，懂網站的都不多，更有誰會去想把一個小項目改來改去的，今天BS，明天非要弄個桌面程序試試呢。對於大項目而言，我覺得還是有必要分層的，即便開發人員不多，甚至一個人去做的話，也還是有必要分層的。分層之后，可以把思路集中在考慮某個層上。不過話又說回來，大項目的分層，我想每個公司之間或者每個人之間的分層定位也不會分的那么特別清楚。
從CSDN上看到一篇貼子，其中有對於分層的舉例說明，個人覺得還是非常淺顯易懂的，一並貼上。
三層的理解：
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等，不同的數據庫之間也有很大的差異，這些異構的數據對業務邏輯層來講都是透明的，業務邏輯層沒必要了解數據存取的細節。那么如何才能實現這種結構？通常的辦法是為數據（庫）層提供一個接口，業務邏輯層只是調用接口所約定的方法，這樣通過接口就可以實現很多異構數據的存取了。
三層的好處很多：
比如具有靈活性，可以隨意調整組件的位置和服務器的位置，可以增加和修改各個組件，更主要的是具有了商業邏輯的靈活性，因為中間層的商業邏輯層負責商業邏輯。
比如說容易更新，不用重新編譯整個工程就可以更新功能，替換一個組件不會擴大影響到整個工程。
比如說容易維護，各層意義明確，不會出現商業邏輯和各種訪問控制混合在一起的情況，而且分層的好處是，各層可以使用不同的配置，各個服務器的維護也變得簡單。
比如說有天生的網絡化，只要配置好一個外部環境，各個組件運行時不會注意到自己訪問的是網絡資源還是本地資源，這種分布式的好處對於一個企業來說是急需的。
分層，無非就是松耦合，便於維護，也便於理解
沒錯，你們一個人做一個模塊，但是如果再給你一個模塊，那么連接數據庫的那些代碼你是不是又要重寫一遍？
或者說，你要再拷貝過來一份，如果出了Bug，你是不是10個模塊都要去修改？
對數據庫的訪問可以單獨做成一個項目，然后引用到你做的所有模塊中去
這個是我認為的分出數據層的意義
表現層和業務層分開，舉個例子：工資計算，今天老板說：工資都是底薪加獎金，
好，做了個程序，10個頁面都用這個公式計算，並顯示工資
明天老板說，工資制度改革，改成底薪+獎金*表現的百分比
這時你所有牽涉到計算業務的地方都要改了
如果所有頁面都只用於顯示工資，計算放到業務層做，這樣就只要改業務層關於計算的地方就好了