什麽是三層架構？各層的主要功能及相互關系有哪些
數據訪問層DAL，業務邏輯層BLL。表現層UI （界面類的） model（數據模型層，主要放的我就不用說了。壹般都是數據庫中的。） ，model是貫穿的。所有的都引用它，bll引用dal ui引用dal 和bll 然後就是調用
三層體系結構，是在客戶端與數據庫之間加入了壹個“中間層”，也叫組件層。這裏所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結構，也不僅僅有B/S應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到壹臺機器上。
普通三層：數據訪問層DAL：用於實現與數據庫的交互和訪問，從數據庫獲取數據或保存數據到數據庫的部分。 業務邏輯層BLL：業務邏輯層承上啟下，用於對上下交互的數據進行邏輯處理，實現業務目標。 表示層UI：主要實現和用戶的交互，接收用戶請求或返回用戶請求的數據結果的展現，而具體的數據處理則交給業務邏輯層和數據訪問層去處理。業務實體Model：用於封裝實體類數據結構，壹般用於映射數據庫的數據表或視圖，用以描述業務中客觀存在的對象。Model分離出來是為了更好地解耦，為了更好地發揮分層的作用，更好地進行復用和擴展，增強靈活性。 通用類庫Common：通用的輔助工具類
工程模式：簡單工廠模式又稱為靜態工廠方法（Static Factory Method）模式，屬於類的創建型模式，通常根據壹個條件（參數）來返回不同的類的實例。
工廠角色（Creator）
是簡單工廠模式的核心，它負責實現創建所有具體產品類的實例。工廠類可以被外界直接調用，創建所需的產品對象。
抽象產品角色（Product）
是所有具體產品角色的父類，它負責描述所有實例所***有的公***接口。
具體產品角色（Concrete Product）
繼承自抽象產品角色，壹般為多個，是簡單工廠模式的創建目標。工廠類返回的都是該角色的某壹具體產品。
通常情況下，客戶端不直接與數據庫進行交互，而是通過COM/DCOM通 訊與中間層建立連接，再經由中間層與數據庫進行交換.
完善的三層結構的要求是:修改表現層而不用修改邏輯層,修改邏輯層而不用修改數據層 否則妳的應用是不是多層結構,或者說是層結構的劃分和組織上是不是有問題就很難說. 不同的應用有不同的理解，這是壹個概念的問題．
MVC系統中的模型從概念上可以分為兩類――系統的內部狀態和改變系統狀態的動作。模型是妳所有的商業邏輯代碼片段所在。本文為模型提供了業務實體對象和業務處理對象：所有的業務處理對象都是從ProcessBase類派生的子類。業務處理對象封裝了具體的處理邏輯，調用業務邏輯模型，並且把響應提交到合適的視圖組件以產生響應。業務實體對象可以通過定義屬性描述客戶端表單數據。所有業務實體對象都EntityBase派生子類對象，業務處理對象可以直接對它進行讀寫，而不再需要和request、response對象進行數據交互。通過業務實體對象實現了對視圖和模型之間交互的支持。實現時把"做什麽"（業務處理）和"如何做"（業務實體）分離。這樣可以實現業務邏輯的重用。由於各個應用的具體業務是不同的，這裏不再列舉其具體代碼實例。
MVC（模型Model-視圖View-控制器Controller）是壹種設計模式，我們可以用它來創建在域對象和UI表示層對象之間的區分。 同樣是架構級別的，相同的地方在於他們都有壹個表現層，但是他們不同的地方在於其他的兩個層。 在三層架構中沒有定義Controller的概念。這是我認為最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是采用三層架構或MVC搭建程序最主要的區別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不壹樣的，“三層”中典型的Model層是以實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。
在ASP NET中的MVC架構編寫的，具有極其良好的可擴展性。它可以輕松實現以下功能： ①實現壹個模型的多個視圖；②采用多個控制器；③當模型改變時，所有視圖將自動刷新；④所有的控制器將相互獨立工作。這就是MVC架構的好處，只需在以前的程序上稍作修改或增加新的類，即可輕松增加許多程序功能。以前開發的許多類可以重用，而程序結構根本不再需要改變，各類之間相互獨立，便於團體開發，提高開發效率。下面討論如何實現壹個模型、兩個視圖和壹個控制器的程序。其中模型類及視圖類根本不需要改變，與前面的完全壹樣，這就是面向對象編程的好處。對於控制器中的類，只需要增加另壹個視圖，並與模型發生關聯即可。該模式下視圖、控制器、模型三者之間的示意圖如圖2所示。同樣也可以實現其它形式的MVC例如：壹個模型、兩個視圖和兩個控制器。從上面可以看出，通過MVC架構實現的應用程序具有極其良好的可擴展性，是ASP NET面向對象編程的未來方向。
MVC的不足體現在以下幾個方面：（1）增加了系統結構和實現的復雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率。（2）視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。3）視圖對模型數據的低效率訪問。依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。（4）目前，壹般高級的界面工具或構造器不支持MVC架構。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。
三層架構是將代碼按其作用分成三部分,每部分解決自己負責的流程. 三層架構的功用之處,在於駕馭大型web程序的結構,使之便於管理和擴展.
在設計UI的時候,我們不需要關心其中的邏輯和數據問題,只需要空出對應的位置,用於放置數據. 在設計和修改的時候,要解決的只是HTML的結構,代碼看起來幹凈利落,做起來也是幹凈利落.
UI直接將程序邏輯的任務丟給BLL,BLL就開始構建具體的實現細節.BLL的創建依賴於業務. 例如壹個文章系統,BLL_Aticle就表示它是用於對文章的處理的.BLL_Aticle可以提供給UI壹個文章列表的recordset,顯示在UI的預留位置. 當BLL_Aticle需要從數據庫中獲取數據的時候,就將任務丟給DAL層
DAL層專門負責和數據庫打交道,它從BLL獲取參數,組織壹個有效的SQL,建立數據庫連接,執行SQL進行更新或獲取,將返回的數據交給BLL.
每壹部分的業務都集中於壹個UI-BLL-DAL的鏈中,上下清晰了然. 至於是怎樣的便於管理和擴展,將在後面結合實例進行分析.
復雜的生命形式必有復雜的生存法則,若想在自己的項目中應用好三層架構,需要多用點心體會其中的應用法則.
我對三層架構的理解還不夠深,這些文章能算是拋磚引玉就不錯了.大家在閱讀當中不要局限於我所構思的法則,要多向具體的應用中去實踐,根據具體情況,尋出自己的法則. 有所感悟,就記得寫下來,這種感悟是進步的契機,但必然不是最終的結果.有了感悟就拿去應用,可以發現它的優劣,繼續完善
三層架構比雙層或單層結構都有更大的優勢。三層結構適合群體開發，每人可以有不同的分工，協同工作使效率倍增。開發雙層或單層應用時，每個開發人員都應對系統有較深的理解，能力要求很高，開發三層應用時，則可以結合多方面的人才，只需少數人對系統全面了解，從壹定程度工降低了開發的難度。
三層架構屬於瘦客戶的模式，用戶端只需壹個較小的硬盤、較小的內存、較慢的CPU就可以獲得不錯的性能。相比之下，單層或胖客戶對面器的要求太高。
三層架構的另壹個優點在於可以更好的支持分布式計算環境。邏輯層的應用程序可以有多個機器上運行，充分利用網絡的計算功能。分布式計算的潛力巨大，遠比升級CPU有效。
三層架構的最大優點是它的安全性。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了。