“三層結構”是什么？
　　“三層結構”一詞中的“三層”是指：“表現層”、“中間業務層”、“數據訪問層”。其中：
n            表　現　層：位于最外層（最上層），離用戶最近。用于顯示數據和接收用戶輸入的數據，為用戶提供一種交互式操作的界面。
n            中間業務層：負責處理用戶輸入的信息，或者是將這些信息發送給數據訪問層進行保存，或者是調用數據訪問層中的函數再次讀出這些數據。中間業務層也可以包括一些對“商業邏輯”描述代碼在里面。
n            數據訪問層：僅實現對數據的保存和讀取操作。數據訪問，可以訪問數據庫系統、二進制文件、文本文檔或是XML文檔。
   

 
　　對依賴方向的研究將是本文的重點，數值返回方向基本上是沒有變化的。


在一個
　　如果只以分層的設計角度看，Duwamish7要比PetShop3.0復雜一些！而如果較為全面的比較二者，PetShop3.0則顯得比較復雜。但我們先不討論這些，對PetShop3.0和Duwamish7的研究，并不是本文的重點。現在的問題就是：既然“三層結構”已經被分派到各自的項目中，那么剩下來的項目是做什么的呢？例如PetShop3.0中的“Model”、“IDAL”、“DALFactory”這三個項目，再例如Duwamish7中的“Common”項目，還有就是在Bincess.CN彬月論壇中的“Classes”、“DbTask”、這兩個項目。它們究竟是做什么用的呢？ 
 
對“三層結構”的深入理解——從一家小餐館說起
　　一個“三層結構”的Web應用程序，就好象是一家小餐館。
n            表　現　層，所有的.aspx頁面就好像是這家餐館的菜譜。
n            中間業務層，就像是餐館的服務生。
n            數據訪問層，就像是餐館的大廚師傅。
n            而我們這些網站瀏覽者，就是去餐館吃飯的吃客了……
 

 
我們去一家餐館吃飯，首先得看他們的菜譜，然后喚來服務生，告訴他我們想要吃的菜肴。服務生記下來以后，便會馬上去通知大廚師傅要烹制這些菜。大廚師傅收到通知后，馬上起火燒菜。過了不久，服務生便把一道一道香噴噴的、熱氣騰騰的美味端到我們的桌位上——
而我們訪問一個基于asp.net技術的網站的時候，首先打開的是一個aspx頁面。這個aspx頁面的后臺程序會去調用中間業務層的相應函數來獲取結果。中間業務層又會去調用數據訪問層的相應函數來獲取結果。 
為什么需要“三層結構”？——初探，就從數據庫的升遷開始
一個站點中，訪問數據庫的程序代碼散落在各個頁面中，就像夜空中的星星一樣繁多。這樣一動百動的維護，難度可想而知。最難以忍受的是，對這種維護工作的投入，是沒有任何價值的……
有一個比較好的解決辦法，那就是將訪問數據庫的代碼全部都放在一個程序文件里。這樣，數據庫平臺一旦發生變化，那么只需要集中修改這一個文件就可以了。我想有點開發經驗的人，都會想到這一步的。這種“以不變應萬變”的做法其實是簡單的“門面模式”的應用。如果把一個網站比喻成一家大飯店，那么“門面模式”中的“門面”，就像是飯店的服務生，而一個網站的瀏覽者，就像是一個來賓。來賓只需要發送命令給服務生，然后服務生就會按照命令辦事。至于服務生經歷了多少辛苦才把事情辦成？那個并不是來賓感興趣的事情，來賓們只要求服務生盡快把自己交待事情辦完。我們就把ListLWord.aspx.cs程序就看成是一個來賓發出的命令，而把新加入的LWordTask.cs程序看成是一個飯店服務生，那么來賓發出的命令就是：
“給我讀出留言板數據庫中的數據，填充到DataSet數據集中并顯示出來！”
而服務生接到命令后，就會依照執行。而PostLWord.aspx.cs程序，讓服務生做的是：
“把我的留言內容寫入到數據庫中！”
而服務生接到命令后，就會依照執行。這就是TraceLWord2！可以