最常用的架構是三層架構。

1.UITier（UserInterface,用戶接口層）

表示層完成向用戶展示界面，提供進一步操作的“驅動接口”，例如按鈕，并顯示結果。

2.BusinessTier（商業層）

完成數據加工，提供加工后的數據給表示層，或者數據層。又可以分為BLL(BusinessLogicLayer,商業邏輯)和DAL(DataAccessLayer,數據訪問)。DAL負責存取數據，BLL負責對DAL層操作，對數據進行運算和操作。BLL也負責響應表示層的事件。

3.DataTier（數據層）

完成數據存儲功能。可能是數據庫、數據源、XML、文本文件等。

這樣就把數據、業務、顯示分開了。UI層只負責顯示給用戶看，至于數據怎么處理運算，由BLL進行并響應，處理完的數據，怎么存取由DAL層進行，數據怎么存在介質上由Data層完成，DAL就不用管。各層之間相對比較獨立，物理依賴性就不那么高了，有時候就只需要編譯改動過的層。

一般對開發和設計人員來說，只需要對UI,BLL,DAL進行設計開發，DATATier由OS或者DBMS來進行，你只需要按“格式”來存取數據即可。

“三層結構的程序不是說把項目分成DAL,BLL,WebUI三個模塊就叫三層了,下面幾個問題在你的項目里面：

1.UILayer里面只有少量(或者沒有)的SQL語句或者存儲過程調用,并且這些語句保證不會修改數據?

2.如果把UILayer拿掉,你的項目還能在Interface/API的層次上提供所有功能嗎?

3.你的DAL可以移植到其他類似環境的項目嗎?

4.三個模塊,可以分別運行于不同的服務器嗎?

如果不是所有答案都為YES,那么你的項目還不能算是嚴格意義上的三層程序.三層程序有一些需要約定遵守的規則:

1.最關鍵的,UI層只能作為一個外殼,不能包含任何BizLogic的處理過程

2.設計時應該從BLL出發,而不是UI出發.BLL層在API上應該實現所有BizLogic,以面向對象的方式

3.不管數據層是一個簡單的SqlHelper也好,還是帶有Mapping過的Classes也好,應該在一定的抽象程度上做到系統無關

4.不管使用COM+(EnterpriseService),還是Remoting,還是WebService之類的遠程對象技術,不管部署的時候是不是真的分別部署到不同的服務器上,最起碼在設計的時候要做這樣的考慮,更遠的,還得考慮多臺服務器通過負載均衡作集群

所以考慮一個項目是不是應該應用三層/多層設計時,先得考慮下是不是真的需要?實際上大部分程序就開個WebApplication就足夠了,完全沒必要作的這么復雜.而多層結構,是用于解決真正復雜的項目需求的.”

而且三層之間有時候也不用那么嚴格，得根據實際業務邏輯來判斷使用。這也是軟件開發所以沒有一個固定流程的原因。