华南俳烁实业有限公司

　　3、UserModel.cs

　　實(shí)體類，這個(gè)東西，大家可能覺得不好分層。包括我以前在內(nèi)，是這樣理解的：UI?àModel?àBLL?àModel?àDAL,如此則認(rèn)為Model在各層之間起到了一個(gè)數(shù)據(jù)傳輸?shù)臉蛄鹤饔�。不過在這里，我們不是把事情想簡單，而是想復(fù)雜了。

　　Model是什么?它什么也不是!它在三層架構(gòu)中是可有可無的。它其實(shí)就是面向?qū)ο缶幊讨凶罨�本的東西：類。一個(gè)桌子是一個(gè)類，一條新聞也是一個(gè)類，int、string、doublie等也是類，它僅僅是一個(gè)類而已。

　　這樣，Model在三層架構(gòu)中的位置，和int,string等變量的地位就一樣了，沒有其它的目的，僅用于數(shù)據(jù)的存儲(chǔ)而已，只不過它存儲(chǔ)的是復(fù)雜的數(shù)據(jù)。所以如果你的項(xiàng)目中對象都非常簡單，那么不用Model而直接傳遞多個(gè)參數(shù)也能做成三層架構(gòu)。

　　那為什么還要有Model呢，它的好處是什么呢。下面是思考一個(gè)問題時(shí)想到的，插在這里：

　　Model在各層參數(shù)傳遞時(shí)到底能起到做大的作用?

　　在各層間傳遞參數(shù)時(shí)，可以這樣：

　　AddUser(userId,userName,userPassword,…，)

　　也可以這樣：

　　AddUser(userInfo)

　　這兩種方法那個(gè)好呢。一目了然，肯定是第二種要好很多。

　　什么時(shí)候用普通變量類型(int,string,guid,double)在各層之間傳遞參數(shù)，什么使用Model傳遞?下面幾個(gè)方法：

　　SelectUser(int UserId)

　　SelectUserByName(string username)

　　SelectUserByName(string username,string password)

　　SelectUserByEmail(string email)

　　SelectUserByEmail(string email,string password)

　　可以概括為：

　　SelectUser(userId)

　　SelectUser(user)

　　這里用user這個(gè)Model對象囊括了username,password,email這三個(gè)參數(shù)的四種組合模式。UserId其實(shí)也可以合并到user中，但項(xiàng)目中其它BLL都實(shí)現(xiàn)了帶有id參數(shù)的接口，所以這里也保留這一項(xiàng)。

　　傳入了userInfo,那如何處理呢，這個(gè)就需要按照先后的順序了，有具體代碼決定。

　　這里按這個(gè)順序處理

　　首先看是否同時(shí)具有username和password,然后看是否同時(shí)具有email和password,然后看是否有username,然后看是否有email.依次處理。

　　這樣，如果以后增加一個(gè)新內(nèi)容，會(huì)員卡(number)，則無需更改接口，只要在DAL的代碼中增加對number的支持就行，然后前臺增加會(huì)員卡一項(xiàng)內(nèi)容的表現(xiàn)與處理即可。

　　4、UserDAL.cs

　　public IList SelectUsers()：返回所有的用戶信息列表

　　public UserInfo SelectUser(int UserId)：返回指定用戶的相信信息

　　public bool InsertUser(UserInfo User)：新增用戶信息

　　public bool UpdateUser(UserInfo User)：更新用戶信息

　　public void DeleteUser(int UserId)：移除用戶信息

　　很多人最鬧不清的就是數(shù)據(jù)訪問層，到底那部分才算數(shù)據(jù)訪問層呢?有些認(rèn)為數(shù)據(jù)庫就是數(shù)據(jù)訪問層，這是對定義沒有搞清楚，DAL是數(shù)據(jù)訪問層而不是數(shù)據(jù)存儲(chǔ)層，因此數(shù)據(jù)庫不可能是這一層的。也有的把SQLHelper(或其同類作用的組件)作為數(shù)據(jù)訪問層，它又是一個(gè)可有可無的東西，SQLHelper的作用是減少重復(fù)性編碼，提高編碼效率，因此如果我習(xí)慣在乎效率或使用一個(gè)非數(shù)據(jù)庫的數(shù)據(jù)源時(shí)，可以丟棄SQLHelper,一個(gè)可以隨意棄置的部分，又怎么能成為三層架構(gòu)中的一層呢。

　　可以這樣定義：與數(shù)據(jù)源操作有關(guān)的代碼，就應(yīng)該放在數(shù)據(jù)訪問層中，屬于數(shù)據(jù)訪問層

　　5、IUserDAL

　　數(shù)據(jù)訪問層接口，這又是一個(gè)可有可無的東西，因?yàn)镻etshop中帶了它和ClassFactory類工廠，所以有些項(xiàng)目不論需不需要支持多數(shù)據(jù)源，都把這兩個(gè)東西做了進(jìn)來，有的甚至不建ClassFactory而只建了IDAL,然后"IUserDAL iUserDal = new UserDAL();",不知意義何在。這就完全是畫虎不成反類犬了。

　　許多人在這里有一個(gè)誤解，那就是以為存在這樣的關(guān)系：BLL?àIDAL?àDAL,認(rèn)為IDAL起到了BLL和DAL之間的橋梁作用，BLL是通過IDAL來調(diào)用DAL的。但實(shí)際是即使你如此編碼："IUserDAL iUserDal = ClassFacotry.CreateUserDAL();",那么在執(zhí)行"iUserDal.SelectUsers()"時(shí)，其實(shí)還是執(zhí)行的UserDAL實(shí)例，而不是IUserDAL實(shí)例，所以IDAL在三層中的位置是與DAL平級的關(guān)系。

　　通過上面的介紹，基本上將三層架構(gòu)的層次結(jié)構(gòu)說明了。其實(shí)，本人有一個(gè)判斷三層架構(gòu)是否標(biāo)準(zhǔn)的方法，那就是將三層中的任意一層完全替換，都不會(huì)對其它兩層造成影響，這樣的構(gòu)造基本就符合三層標(biāo)準(zhǔn)了(雖然實(shí)現(xiàn)起來比較難^_^)。例如如果將項(xiàng)目從B/S改為C/S(或相反)，那么除了UI以外，BLL與DAL都不用改動(dòng);或者將SQLServer改為Oracle,只需替換SQLServerDAL到OracleDAL,無需其它操作等等。本來想在文中加入一些具體的代碼的，但感覺不是很必要，如果大家覺得需要的話，我再補(bǔ)充吧。

　　總結(jié)：不要因?yàn)槟硞�(gè)層對你來說沒用，或者實(shí)現(xiàn)起來特別簡單，就認(rèn)為它沒有必要，或者摒棄它，或者挪作它用。只要進(jìn)行了分層，不管是幾層，每一層都要有明確的目的和功能實(shí)現(xiàn)，而不要被實(shí)際過程所左右，造成同一類文件位于不同層的情況發(fā)生。也不要出現(xiàn)同一層實(shí)現(xiàn)了不同的功能的情況發(fā)生。