---------------------------------------------------------------------------------------------------華麗的分割線----------------------------------------------------------------------------------------------------------
Model又叫實體類，這個東西，大家可能覺得不好分層。包括我以前在內，是這樣理解的：UI<-->Model<-->BLL<-->Model<-->DAL，如此則認為Model在各層之間起到了一個數據傳輸的橋梁作用。不過在這里，我們不是把事情想簡單，而是想復雜了。
Model是什么？它什么也不是！它在三層架構中是可有可無的。它其實就是面向對象編程中最基本的東西：類。一個桌子是一個類，一條新聞也是一個類，int、string、doublie等也是類，它僅僅是一個類而已。
這樣，Model在三層架構中的位置，和int，string等變量的地位就一樣了，沒有其它的目的，僅用於數據的存儲而已，只不過它存儲的是復雜的數據。所以如果你的項目中對象都非常簡單，那么不用Model而直接傳遞多個參數也能做成三層架構。
那為什么還要有Model呢，它的好處是什么呢。下面是思考一個問題時想到的，插在這里：
Model在各層參數傳遞時到底能起到做大的作用？
在各層間傳遞參數時，可以這樣：
AddUser（userId，userName，userPassword，…，）
也可以這樣：
AddUser（userInfo）
這兩種方法那個好呢。一目了然，肯定是第二種要好很多。
什么時候用普通變量類型（int,string,guid,double）在各層之間傳遞參數，什么使用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這三個參數的四種組合模式。UserId其實也可以合並到user中，但項目中其它BLL都實現了帶有id參數的接口，所以這里也保留這一項。
傳入了userInfo，那如何處理呢，這個就需要按照先后的順序了，有具體代碼決定。
這里按這個順序處理
首先看是否同時具有username和password，然后看是否同時具有email和password，然后看是否有username，然后看是否有email。依次處理。
這樣，如果以后增加一個新內容，會員卡（number），則無需更改接口，只要在DAL的代碼中增加對number的支持就行，然后前台增加會員卡一項內容的表現與處理即可。
----------------------------------------------------------------------------------------------------------華麗的分割線---------------------------------------------------------------------------------------------------