我們在進行機房收費系統時，已經接觸到三層及一些例項，但是三層到底是什麼？我理解的三層是：ui---介面、bll---邏輯層、dal--資料層。但是在做例項時有乙個實體層：entity---實體層
這就是我疑問的開始，為什麼我們不叫做四層呢？實體層在三層中的作用是什麼呢？帶著這些疑問開始自己的學習之旅！ 各方高見:
1.認為實體層只是乙個輔助資料庫對映
2.認為model就是乙個載體，裝到東西可以流走三層。這些冠名堂皇的解釋讓我還是雲裡霧裡。實體層到底是什麼？？
那麼以下就是我結合資料的理解：
三層分別是腦袋，上肢，下肢，那entity就是血液，流動在層次間的資料就像流動在肢體中的血液。雖然dataset也可以當做資料載體而且效率高一些，但是entity更有oo的感覺 。
接下來通過例項來理解實體層：
它在三層架構中是可有可無的。它其實就是物件導向程式設計中最基本的東西：類。乙個桌子是乙個類，一條新聞也是乙個類，int、string、doublie等也是類，它僅僅是乙個類而已。
這樣，entity在三層架構中的位置，和int，string等變數的地位就一樣了，沒有其它的目的，僅用於資料的儲存而已，只不過它儲存的是複雜的資料。所以如果你的專案中物件都非常簡單，那麼不用entity而直接傳遞多個引數也能做成三層架構。
那為什麼還要有entity呢？它的好處是什麼呢？ entity在各層引數傳遞時到底能起到多大的作用？接下來帶著疑問進入思考：
在各層間傳遞引數時，可以這樣：
adduser（userid，username，userpassword，…，）
也可以這樣：
adduser（userinfo）
這兩種方法那個好呢。一目了然，肯定是第二種要好很多。
什麼時候用普通變數型別（int,string,guid,double）在各層之間傳遞引數，什麼使用entity傳遞？下面幾個方法：
selectuser（int userid）
selectuserbyname（string username）
selectuserbyname（string username，string password）
selectuserbyemail（string email）
selectuserbyemail（string email，string password）
可以概括為：
selectuser（userid）
selectuser（user）
這裡用user這個entity物件囊括了username，password，email這三個引數的四種組合模式。userid其實也可以合併到user中，但專案中其它bll都實現了帶有id引數的介面，所以這裡也保留這一項。 傳入了userinfo，那如何處理呢，這個就需要按照先後的順序了，有具體**決定。
這裡按這個順序處理
首先看是否同時具有username和password，然後看是否同時具有email和password，然後看是否有username，然後看是否有email。依次處理。
這樣，如果以後增加乙個新內容，會員卡（number），則無需更改介面，只要在dal的**中增加對number的支援就行，然後前台增加會員卡一項內容的表現與處理即可。
總結：通過以上總結我認為實體層就是乙個在各層傳遞資訊的載體，它可以讓資料的傳遞變得簡潔，並且不會讓各種複雜引數混亂，讓各層間的資訊有序高效傳遞。
三層架構之實體層以及外觀
昨天，七期師兄師姐們給我們講解了一下三層和三正規化。關於三層 對於三層的理解，一直在一步步的加深之中，不論理解的對與錯，至少現在和別人說三層，能說出一點點的皮毛，但是再往深一點說，就不會了。聽了昨天的講解，發現最難理解的其實並不是b層，也不是d層，更不是u層，而是實體層。bll層主管業務邏輯，也就是...
Hibernate 實體層設計
hibernate繼承對映的第一種策略 每棵類繼承樹對應一張表 所有子類資訊都存在一張表裡，用乙個欄位來區分 1 理解如何對映 因為類繼承樹肯定是對應多個類，要把多個類的資訊存放在一張表中，必須有某種機制來區分哪些記錄是屬於哪個類的。這種機制就是，在表中新增乙個字段，用這個欄位的值來進行區分。用hi...
ABP領域層 實體
參考陽光銘睿的教程 實體類 在abp中，實體類繼承自 entity 類public class person entity person類的父類中有 id屬性，id是該實體的主鍵，預設型別是 int,如果想給id定義其他型別，如下，也可以設定為 string,guid public class pe...