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的支持就行，然後前臺增加會員卡一項內容的表現與處理即可。
