三層架構並不是MVC,MVC是一個很早就有的經典的程序設計模式,M-V-C分為三層,M(Model)-V(View)-C(Control)。而web開發中的三層架構是指:數據訪問層(DAL-DatabaseAccessLayer),業務邏輯層(BLL-BusinessLoginLayer),以及用戶界面層(UI-UserInterface,實際就是網頁後台的具體調用BLL層)。這個是基本概念。曾經我以為三層架構就是在AppCode中,分為三個大類與若干小類,各司其職。在經過一番洗禮後,才發覺多麼的無知。
首先AppCode中,放的是通用類,如數據庫通用類,實現數據庫連接,基本的SqlCommand創建,自定義CRUD的方法等,與三層架構毫無關系,就是常用的開發模式中存放類(Class)的文件夾。
其次,當使用三層架構時,一定是在大項目中,因為三層架構的目的是提高項目的松散性和降低項目的耦合度,使之更容易擴展或者維護。小項目使用了三層架構,由於過度的在意分層而導致了項目的復雜度增加。
創建三層架構的應用程序。我們必須對這三層分別創建不同的類庫(ClassLibrary),而不是普通的類(Class)。我們對於任何一個模塊或者功能進行OOP,把它擴展為對象(面向對象的思想就是:將所操作的目標當成一個對象,對它進行的操作,將由對象自己的方法進行,而非外界傳參。譬如注冊用戶,用面向過程的方法事先,就是:public static bool Register(string userName, string userPwd)。若用OO的思想,我們不可將賬號密碼作為參數傳入,而是將用戶作為一個對象,這個對象具有private _userName,和private _userPwd的屬性。在注冊時,用構造函數初始化一個新的對象,User one = new User(userName,userPwd),使之在初始化後具有這兩個字段的值。然後調用User類中的public static bool Register()方法(注意這個方法是不進行傳參的),而在這個Register方法中,使用對象的_userName和_userPwd屬性進行注冊。),那麼,我們在這個對象中的任何操作都將以該對象的方法(函數)實現。
在進行三層分類時,這樣新建類庫。
1.文件->新建項目->其他項目類型->空白解決方案。
2.在右側的“資源管理器”中,選中當前解決方案,右鍵添加->新建項目->類庫(ClassLibrary),分別創建BLL,DAL,UL類庫。(若添加後看不到解決方案則在菜單->工具->選項->項目和解決方案->總是顯示解決方案)。
3.右鍵,向解決方案中添加一個網站(新網站或者現有網站)。
4.根據需求刪除或者保留默認添加項(默認的class1.cs或Default.aspx文件)。
這樣一個三層架構的網站雛形就搭建好了。因為UI層要被其他兩層引用,DAL層要被BLL層引用。所以需要相互添加引用,方法是在類庫上點擊右鍵->添加引用->項目->選擇其他類庫。並且在具體類中引入命名空間(using namespace)。
ps:類庫其實就是類的集合,三層架構的目的就是,將同一項目的不同模塊都劃分為各自的三層,各司其職,將具體實現方法用類寫出,添加到該層的類庫中,這樣,一個網站下的類庫就只有三層,每一層中都包含了各個模塊相對應層的實現方法。在以後修改或擴展時,在對應層中進行操作就可以了。
一般的項目,涉及最多的就是對數據庫的CRUD,DAL層只負責與數據庫的交互,BLL層是最重要的一層,他負責將DAL層的的結果呈現給UI層,但是恰恰BLL層的存在似乎有點雞肋,他起到的僅僅是轉發DAL層數據的作用,而具體的邏輯操作是與數據庫的交互,應該寫在DAL層,這就好像BLL層是在重復DAL層的勞動一樣,其實BLL層的作用在於除了調用DAL層訪問數據庫,還可以進行邏輯判斷,當符合的時候,才進行允許進行DAL的操作,或者進行額外的操作(如加密,轉換等)。而DAL層可不管這些,他只管進行CRUD的動作。UI層就是操作抽象出來的實體對象,它包含了各種屬性。
一個三層架構的小例子:注冊新用戶。
先寫模塊的實體類,是數據庫中表的抽象,假設數據庫中注冊信息只有賬號,密碼兩個字段。那麼抽象到實體類就是這樣:
再寫DAL層:
再寫BLL層:
最後構建UI層代碼,即我們的aspx.cs頁面代碼,該層應該直接調用BLL層的方法。該頁面引用BLL和Entity的命名空間,並向Button控件注冊事件:
這樣一個小的三層架構程序就出來了。
這個程序中,操作的實體為UserInfo表的抽象。在DAL層進行了AddUser()的方法,在BLL層也進行了AddUser()的方法,唯一的區別是BLL層做了邏輯判斷,如果用戶名存在,則注冊失敗。
三層架構的特點:
1.數據庫訪問層(DAL)僅提供對數據庫的CRUD操作,而不管操作後的結果,也不管邏輯過程(譬如同名用戶,不合法用戶名)。
2.業務邏輯層(BLL)不會直接與數據庫交互,他與數據庫的交互是通過DAL提供的方法。在調用這些方法前,要加入自己的邏輯判斷或者業務處理。另外業務邏輯層(BLL)還有可能不會去調用DAL層的方法,而是進行其他業務處理。
3.用戶界面層(UI)層是不會調用DAL層的,他只調用BLL層提供的方法,再由BLL層自己決定是否繼續調用DAL層。
這個例子可以看出三層架構的優點就是結構清晰,容易擴展與維護。缺點就是,復雜。僅僅一個注冊用戶,就這麼麻煩,所以對於小項目來說,費這麼大勁換取一個相對較清晰的分層結構是不劃算的。
轉載請注明出處:csdn-mark