C#三十五 三層架構企業應用

1.1          3層架構簡介

假設你在經營1個大飯店，大體上你會請3方面的人，1方面是負責飯店服務的服務員，1方面是負責烹飪、做飯的廚師，1方面是負責飯店蔬菜、肉類、調料等的采購員。

如果你這樣做了，那末飯店管理起來，就好比較好管理（簡單來講）。比如任何1方面的員工出現請假或離職的情況，可以找其他的服務員、廚師或采購員代替。

在企業中這類職責分離、業務獨立的部門劃分方法對管理企業有很大的好處，一樣在程序中也需采取“職責分離、業務獨立的”的原則劃分模塊，更好的實現“高內聚、低耦合”的軟件設計思想。

1.2為何要使用3層架構

     那末我們為何要使用分層開發呢，它有甚么獨特的優勢呢？

.NET開發平臺為我們做開發提供了強大的技術支持，使我們的開發變得非常便捷，高效。通過code behind的強大支持，我們可以將頁面設計和代碼設計有效的分離，代碼編寫，頁面設計同時進行。

的確，僅從功能實現的基礎來講我們已做得很好了，特別對1個簡單的利用來講，代碼量不是很多的情況下，這類1層結構開發完全夠用了，沒有必要弄得那末復雜。但是對1個復雜的大型系統來講這樣的設計的缺點就很嚴重了。

在開發進程中我們會不停把代碼到處復制，以實現1些相似的功能。一樣的代碼為何要寫那末屢次？不但使程序變得冗雜，更不利于保護，1個小小的修改也許會波及很多頁面。略微不留心就會致使異常的產生，使程序不能正常運行。最主要的面向對象的思想沒有得到絲毫的體現，打著面向對象的幌子卻仍然走著面向進程的老路。

意想到這樣的問題，我開始將程序中1些公用的處理程序寫成公共方法封裝在類中，供其它程序調用。象1些功能型的代碼集合，數據庫操作，猶如SqlHelper那樣對數據操作進行公道封裝，把sql語句，參數列表作為參數，在數據庫操作進程中，只要傳入相應的參數就能夠完成特定的數據操作，這就是我1開始的數據訪問層，再不用每次操作數據庫時都寫那些重復性的數據庫操作代碼。在新的利用開發中，數據訪問層可以直接拿來用。

面向對象的3大特性之1的封裝性在這里得到了很好的體現。似乎找到了面向對象的感覺，代碼量較之前有了很大的減少，而且修改的時候也比較方便。這下應當可以了吧？

試問1下，如果有1天數據庫供應商產生了變化，由于數據量的增加，數據庫有access變成了sql server？這下麻煩大了，原來的數據訪問層失效了，數據操作對象產生了變化，且頁面中觸及數據對象的地方也要進行修改，由于原來可能會使用OleDbDataReader對象將數據傳遞給顯示頁面，現在都得換成SqlDataReader對象，sql和access支持的數據類型也不1致，在顯示數據時進行的數據轉換可能也要進行修改。由sql向access的轉換所做的修改會更多。

還有1種情況，由于某種需要，我們要把Web情勢的項目改造成windows利用，這時候牽涉的修改有多大呢？如果在你的aspx.cs中放了很多處理代碼，或還有1部份代碼存在于aspx中呢windows利用中可沒有aspx阿，是否是全部系統需要重新來做了？這都是設計不公道惹的禍。

1.3          3層架構的構成

我們通常說的3層架構包括表示層、業務層和數據層3層，對利用系統來講，表示層和用戶交互并顯示數據，業務層負責訪問數據層并向表示層提交數據，數據層負責數據的存儲。下面來詳細論述3層架構的含義及其組成：

n       表示層

它主要是指與用戶交互的界面，它接收用戶的輸入，但其實不包括任何實際的業務處理，它只是簡單地講數據轉交給業務層，同時負責展現業務層傳遞過來的數據，當后臺業務邏輯更新時，表示層就會顯示這些更新。表示層提供利用程序的用戶界面（UI），通常包括Windows窗體、Asp.NetWeb窗體。

n       業務層

它代表了利用程序的核心功能，負責處理數據層的數據，實現業務邏輯，用于實現某種規則的業務處理以匹配特定公司的需要。例如，肯定某個指定客戶是不是被批準進行某項借貸活動的業務規則可以封裝在小型解決方案的客戶業務組件中。對大型解決方案，所有與借貸有關的業務邏輯可能都封裝在單獨的1個借貸組件中。

n       數據層

數據訪問層：有時候也稱為是持久層，其功能主要是負責數據庫的訪問，可以訪問數據庫系統、2進制文件、文本文檔或是XML文檔。簡單的說法就是實現對數據表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那末就會包括對象和數據表之間的mapping，和對象實體的持久化。

將3層架構與飯店的各個人員層相比較的圖以下：

3層結構的優點

1)從開發角度和利用角度來看，3層架構比雙層或單層結構都有更大的優勢。3層結構合適群體開發，每人可以有不同的分工，協同工作使效力倍增。開發雙層或單層利用時，每一個開發人員都應對系統有較深的理解，能力要求很高，開發3層利用時，則可以結合多方面的人材，只需少數人對系統全面了解，從1定程度工下降了開發的難度

2)3層架構可以更好的支持散布式計算環境。邏輯層的利用程序可以有多個機器上運行，充分利用網絡的計算功能。散布式計算的潛力巨大，遠比升級CPU有效。美國人曾利用分式計算解密，幾個月就破解了據稱永久都破不了的密碼

3)也是3層架構的最大優點是它的安全性。用戶端只能通過邏輯層來訪問數據層，減少了入口點，把很多危險的系統功能都屏蔽了

3層結構的缺點
“金無足赤，人無完人”，分層式結構也不可避免具有1些缺點：
1、下降了系統的性能。這是不言而喻的。如果不采取分層式結構，很多業務可以直接造訪數據庫，以此獲得相應的數據，如今卻必須通過中間層來完成。
2、有時會致使級聯的修改。這類修改特別體現在自上而下的方向。如果在表示層中需要增加1個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼。

2.2點擊新建項—》，選擇，利用程序配置文件

2.3打開app.config文件后，寫以下代碼：

/*在此先弱化了，業務邏輯層*/

第6步：表示層

這樣，全部完全、簡單的3層框架登錄已基本完成。

請沒有完成的同學依照此步驟，務必做完。體驗3層框架之間類的調用與關系。

/*針對3層當中的各個“相干責任類”，添加斷點，進行測試，看看參數傳遞效果。*/

下面同學們，連接項目組長的數據庫服務器。

打開TCP/IP和其他服務

小結：

n       3層結構與兩層結構的區分是甚么？

n       為何要實現分層？各層的作用是甚么？

n       3層結構中各層之間相互依賴是如何實現的？

作業：

   自己根據之前坐的賓館管理系統、汽車銷售系統等C/S系統，根據3層架構的思想，重新搭建新的框架。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈