Model在各層參數(shù)傳遞時到底能起到做大的作用？
在各層間傳遞參數(shù)時，可以這樣：
AddUser（userId,userName,userPassword,…，）
也可以這樣：
AddUser（userInfo）
這兩種方法那個好呢。一目了然，肯定是第二種要好很多。
什么時候用普通變量類型（int,string,guid,double）在各層之間傳遞參數(shù)，什么使用Model傳遞？下面幾個方法：
SelectUser（int UserId）
SelectUserByName（string username）
SelectUserByName（string username,string password）
SelectUserByEmail（string email）
SelectUserByEmail（string email,string password）
可以概括為：
SelectUser（userId）
SelectUser（user）
這里用user這個Model對象囊括了username,password,email這三個參數(shù)的四種組合模式。UserId其實也可以合并到user中，但項目中其它BLL都實現(xiàn)了帶有id參數(shù)的接口，所以這里也保留這一項。
傳入了userInfo,那如何處理呢，這個就需要按照先后的順序了，有具體代碼決定。
這里按這個順序處理
首先看是否同時具有username和password,然后看是否同時具有email和password,然后看是否有username,然后看是否有email.依次處理。
這樣，如果以后增加一個新內(nèi)容，會員卡（number），則無需更改接口，只要在DAL的代碼中增加對number的支持就行，然后前臺增加會員卡一項內(nèi)容的表現(xiàn)與處理即可。
4、UserDAL.cs
public IList<UserInfo> 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ù)存儲層，因此數(shù)據(jù)庫不可能是這一層的。也有的把SQLHelper（或其同類作用的組件）作為數(shù)據(jù)訪問層，它又是一個可有可無的東西，SQLHelper的作用是減少重復(fù)性編碼，提高編碼效率，因此如果我習(xí)慣在乎效率或使用一個非數(shù)據(jù)庫的數(shù)據(jù)源時，可以丟棄SQLHelper,一個可以隨意棄置的部分，又怎么能成為三層架構(gòu)中的一層呢。
可以這樣定義：與數(shù)據(jù)源操作有關(guān)的代碼，就應(yīng)該放在數(shù)據(jù)訪問層中，屬于數(shù)據(jù)訪問層
5、IUserDAL
數(shù)據(jù)訪問層接口，這又是一個可有可無的東西，因為Petshop中帶了它和ClassFactory類工廠，所以有些項目不論需不需要支持多數(shù)據(jù)源，都把這兩個東西做了進(jìn)來，有的甚至不建ClassFactory而只建了IDAL,然后"IUserDAL iUserDal = new UserDAL（）；",不知意義何在。這就完全是畫虎不成反類犬了。
許多人在這里有一個誤解，那就是以為存在這樣的關(guān)系：BLL?àIDAL?àDAL,認(rèn)為IDAL起到了BLL和DAL之間的橋梁作用，BLL是通過IDAL來調(diào)用DAL的。但實際是即使你如此編碼："IUserDAL iUserDal = ClassFacotry.CreateUserDAL（）；",那么在執(zhí)行"iUserDal.SelectUsers（）"時，其實還是執(zhí)行的UserDAL實例，而不是IUserDAL實例，所以IDAL在三層中的位置是與DAL平級的關(guān)系。
通過上面的介紹，基本上將三層架構(gòu)的層次結(jié)構(gòu)說明了。其實，本人有一個判斷三層架構(gòu)是否標(biāo)準(zhǔn)的方法，那就是將三層中的任意一層完全替換，都不會對其它兩層造成影響，這樣的構(gòu)造基本就符合三層標(biāo)準(zhǔn)了（雖然實現(xiàn)起來比較難^_^）。例如如果將項目從B/S改為C/S（或相反），那么除了UI以外，BLL與DAL都不用改動；或者將SQLServer改為Oracle,只需替換SQLServerDAL到OracleDAL,無需其它操作等等。本來想在文中加入一些具體的代碼的，但感覺不是很必要，如果大家覺得需要的話，我再補(bǔ)充吧。
總結(jié)：不要因為某個層對你來說沒用，或者實現(xiàn)起來特別簡單，就認(rèn)為它沒有必要，或者摒棄它，或者挪作它用。只要進(jìn)行了分層，不管是幾層，每一層都要有明確的目的和功能實現(xiàn)，而不要被實際過程所左右，造成同一類文件位于不同層的情況發(fā)生。也不要出現(xiàn)同一層實現(xiàn)了不同的功能的情況發(fā)生。
