壹般講到三層架構，其實就是將整個業務應用劃分為表示層、業務邏輯層、數據訪問層等。
數據訪問層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有效。
三層架構的最大優點是它的安全性。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了。
vs三層架構之間的關系 ？client -midware -server
可以這樣理解：
client 把要求提供給midware
midware 提供服務給 client
midware 把要求提供給server
server 提供服務給 midware
只所以用midware,因為client變化大，
現在不只3層了
類與類之間的依賴關系是怎樣的對於兩個相對獨立的系統，當壹個系統負責構造另壹個系統的實例，或者依賴另壹個系統的服務時，這兩個系統之間主要體現為依賴關系.
C#的三層架構各層之間到底怎麽傳遞數據的啊？可以用屬性賦值傳，也可以用方法參數傳。
mvc與三層架構的關系是怎麽樣的三層是從整個應用程序架構的角度來分的三層（如果程序需要，還可以分多層）。
三層是為了解決整個應用程序中各個業務操作過程中不同階段的代碼封裝的問題，為了使程序員更加專註的處理某階段的業務邏輯。
比如將數據庫操作代碼封裝到壹層中，提供壹些方法根據參數直接返回用戶需要的相應數據，這樣在處理具體的業務邏輯的時候，就不用關心數據的存儲問題了。
MVC是在應用程序（BS結構）的視圖層劃分出來的不同功能的幾個模塊。
MVC主要是為了解決應用程序用戶界面的樣式替換問題，把展示數據的 HTML 頁面盡可能的和業務代碼分離。MVC把純凈的界面展示邏輯（用戶界面）獨立到壹些文件中（Views），把壹些和用戶交互的程序邏輯（Controller）單獨放在壹些文件中，在 Views 和 Controller 中傳遞數據使用壹些專門封裝數據的實體對象，這些對象，統稱為Models。
只所以說MVC和三層毫無關系，是因為它們二者使用範圍不同：三層可以應用於任何語言、任何技術的應用程序；而MVC只是為了解決BS應用程序視圖層各部分的耦合關系。它們互不沖突，可以同時存在，也可根據情況使用其中壹種。
三層架構中各層如何傳遞多個對象
public class Person
{
public string name{get;set;}
public int age{get;set}
}
然後把Person對象傳過去就好了
傳遞多個對象，主要看架構者的手段
1.有些人通過Bil去對外提供服務，那麽UI的對象依靠bil提供，bil則依靠model或者dal提供
2.有些人通過mvc方式提供，那麽他則會根據control控制去獲得view視圖對象，通過這個視圖對象來完成UI到邏輯的傳遞，至於邏輯本身如何向下傳遞則同1
ps：其實個人認為不必去管這些，與壹些人以壹層不變的model不同，我們認為其實各層封裝各層自己的viewmodel，妳自己根據需要靈活組合，拆解就ok
比如在UI層，為了綁定方便，我們可以有UI的viewmodel
在邏輯層，為了提供不同動作的服務我們則可以繼承，組合，裝飾，拆解不同對象以提供邏輯層的業務邏輯對象。
而數據層，同樣如此。數據庫表不等於模型對象，模型對象也不是數據庫表。壹個模型對象可以被拆分成多個表，壹個表可能會是多個模型對象的數據提供。
所以不必強求用壹套統壹的model去搞定他，要知道OO本身就是封裝，繼承，多態。妳都強行把自己弄成壹個壹成不變的model，本身就不是OO的對象了。那個是c語言的結構體了
什麽是數學知識之間的依賴關系？數學知識之間的依賴關系，也就是知識的綜合應用問題，知識點之間與知識點之間有練習，對於某些練習題來說，若某些知識點沒有及時掌握的話，會影響解題。下面這個例子就是應用數學知識之間的依賴關系解題的。1.在Rt△ABC中（AB是斜邊），BC=7cm，AC=24cm，點p在BC上，從B點到C點運動（不包括C點），點P運動的速度為2cm/s；Q點在AC上從C點運動到A點（不包括A點），速度為5cm/s.若點P、Q分別從B、C同時運動。
過程
設P運動x秒時，則BP=2x，CQ=5x
S△PCQ=5x*（7-2x）/2
=-5*（x? -7x/2+49/16）+245/16
=-5*（x-7/4)?+245/16
即當x=7/4（秒）時，△PCQ的面積最大，最大面積是245/16
2.在ΔABC中,D為BC的中點,E為AC上的任意壹點,BE交AD於點O．某學生在研究這壹問題時,發現了如下事實: 如圖1,當 時,有 ；
如圖2,當 時,有 ；
如圖3,當 時,有 ；在圖4中,當 時,
參照上述研究的結論,請妳猜想用n表示AO∶AD的壹般結論,並給出證明
結論: AE∶AC=1∶(1+n)時,
AO∶AD=2∶(2+n)．
證明:如圖4,作DF‖BE,交AC於F．
∵BD=DC,∴EF=FC．
∵AE∶AC=1∶(1+n),∴AE∶EC=1∶n=2∶2n．
∴AE∶EF=2∶n．
∴AO∶AD=AE∶EF=2∶(2+n) 數理化專團作答
註入怎麽解決組件之間的依賴關系Spring 從核心而言，是壹個DI 容器，其設計哲學是提供壹種無侵入式的高擴展性框架。即無需代碼中涉及Spring專有類，即可將其納入Spring容器進行管理