❶ ASP.NET三層架構
為何使用N層架構？
因為每一層都可以在僅僅更改很少量的代碼後，就能放到物理上不同的伺服器上使用，因此結構靈活而且性能更佳。此外，每層做些什麼其它層是完全看不到的，因此更改、更新某層，都不再需要重新編譯或者更改全部的層了。這是個很強大的功能。例如，如果把數據訪問代碼與業務邏輯層分離，當資料庫伺服器更改後，你只需要更改數據訪問的代碼，因為業務邏輯層是不變的，因此不需要更改或者重新編譯業務邏輯層。
一個N層的應用程序通常有三層：表現層、業務層和數據層。下面讓我們看看每層都做些什麼。
表現層（Presentation Layer）
表現層用於用戶介面的展示，以及用業務層的類和對象來「驅動」這些介面。
在ASP.NET中，該層包括aspx頁面、用戶控制、伺服器控制以及某些與安全相關的類和對象。
業務層（Business Tier）
業務層用於訪問數據層，從數據層取數據、修改數據以及刪除數據，並將結果返回給表現層。
在ASP.NET中，該層包括使用SqlClient或OleDb從SQL Server或Access資料庫取數據、更新數據及刪除數據，並把取得的數據放到DataReader或DataSet中返回給表現層。返回的數據也許只有一個整型數字，比如一個表的行記錄數目，但這也要用數據層的數據進行計算。
BLL和DAL
通常該層被劃分成兩個子層：業務邏輯層（Business Logic Layer，BLL）和數據訪問層（Data Access Layers，DAL）。業務邏輯層在數據訪問層之上，也就是說BLL調用DAL的類和對象。DAL訪問數據並將其轉給BLL。
在ASP.NET中，該層可以用SqlClient或OleDb從SQL Server或Access資料庫取數據，把數據通過DataSet 或DataReader的形式給BLL，BLL處理數據給表現層。有的時候，例如直接把DataSet 或DataReader送給表現層的時候，BLL是一個透明層。
數據層（Data Tier）
數據層是資料庫或者數據源。在.NET中，通常它是一個SQL Server或Access資料庫，但不僅限於此兩種形式，它還可能是Oracle，mySQL，甚至是XML。
邏輯層VS（分布式）物理層
人們容易將這兩個概念搞混。我們說邏輯層是把層按類的集合來劃分，而這些層都在同一台個伺服器上。（分布式）物理層是指類的集合在不同的伺服器上，用附加的代碼來處理層間的通信，比如remoting和web服務。
決定如何劃分你的層（是物理的還是不是物理的）是非常重要的。在劃分時應考慮下面因素：
1、注意如果劃分成物理層，你的應用程序的速度會因為不同伺服器在網路中通信的延遲而減慢。所以，如果你決定用物理層，請確保獲得性能的提升大於性能的降低。
2、按照n層架構設計你的應用程序。
3、部署以及維護物理分布式的應用程序的成本是很高的。你首先需要不止一台伺服器，你還需要網路硬體來連接這些伺服器。在這種情況下，部署應用變得更加復雜！因此這樣做之前請確定這樣做是否值得。
另外還要注意，你的應用程序的每層都做何使用。你也許因為運行的多個服務都需要某一層而把該層放到別台伺服器上。例如，你也許會因為給不同的用戶定製不同的表現層，而將業務邏輯層放於別處；你也許會因為還有其它的應用訪問同一個資料庫，而把SQL server服務放到別處。
❷ asp.net三層架構中，是不是不需要用到資料庫的都可以在表示層直接寫代碼還是說表示層都是要調用業務層的
不用到資料庫,就沒有數據訪問層,那你建的項目就不是三層架構.如果你使用了三層的話,表示層還是要調用業務層的.
使用三層是為了「高內聚，低耦合」的思想,使得開發人員的分工更加明確,降低層與層間的依賴性，既可以良好地保證未來的可擴展，在復用性上也是優勢明顯。
表示層:也就是界面層,給用戶看到
業務層:對數據業務邏輯處理
數據訪問層:對數據的增、刪、改、查等.
用戶提交了一個請求,先傳遞到業務層,業務層進行處理,再轉到數據訪問層,數據訪問層,在對資料庫進行相關的操作,得到一個結果,再傳到業務層,業務層處理完了之後,返回給界面層,最終響應給了用戶.
❸ 關於ASP.NET三層架構的問題
控制項綁定了數據源 不一定違背三層架構，關鍵是你的數據源是如何得到的。
1、你指的數據源就是資料庫里的某個表或某些數據。
2、你指的數據源是通過業務邏輯層取得的對象列表。
前者這樣處理沒有使用三層架構，後者則使用了架構。
如果你不使用架構，那麼如果將來你的系統業務需求發生變更，可能會導致你重新根據條件綁定數據源，如果用了架構你只需要修改業務邏輯層相應的方法。
分層架構的優點就是便於維護，如果你都是以綁定數據源的方式實現，那麼一個業務發生變化，可能你要修改很多個綁定的控制項。
❹ asp.net中要用到三層架構嗎用的好處是什麼
不過,我覺得任何事情都不要這么絕對,小項目你分那麼清楚干什麼?怎麼方便怎麼寫就對了
中小型的,就考慮一下分點層出來,主要還是方便維護~~~
中型項目要在項目開始前有一個比較好的規劃,如何劃分層次結構,但是還不至於必須一個表一個類,多表關聯可以搞死你~~~
大型項目的話,架構就比較復雜了,光數據訪問層就可以分為至少兩部分,而且一般的層次結構幾乎無法適應所有的CASE,這個時候就要用一些辦法了,當然,這些辦法主要還是那些模式,這樣可以組合出適合你的項目的層次結構出來.(說白了,MVC不就是這樣的嗎?)
也不要總是三層三層的,有的時候3層多餘,有的時候明顯不夠.比如說,我們現在正在研發的一個數據平台,初步劃分為6層,在評審的時候已經發現不足了,還得再繼續分下去……
綜上所述,不要太過絕對,不分層的小軟體不一定不是好軟體(不過只要是軟體,總能分點層出來),分層的也不一定就是什麼好玩意兒，「合適的」才是「最好的」～～～
❺ .net網站是不是說用三層架構做的比不用三層架構的好
分層是趨勢，但小項目上優勢體現不出來。所以當是學習。架構的學習是很有必要的。
❻ .net Web網站不使用三層架構,MVC模式（啥都沒用）的弊端
耦合度太高, 不利於代碼維護和閱讀
不過小項目的話不要緊, 分層反而變得很麻煩