net的架構？

1. UI Tier（User Interface, 用戶接口層）

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

2. Business Tier（商業層）

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

3. Data Tier（數據層）

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

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

一般對開發和設計人員來說，只需要對UI, BLL, DAL 進行設計開發，DATA Tier由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+(Enterprise Service), 還是Remoting, 還是WebService之類的遠程對象技術, 不管部署的時候是不是真的分別部署到不同的服務器上, 最起碼在設計的時候要做這樣的考慮, 更遠的, 還得考慮多臺服務器通過負載均衡作集群

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

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