在我的qq群裡，有q友談到實體類是否應該擁有行為的話。有人說不，有人說可。爭執不下，我的理解是這樣的。
如果實體類沒有行為，則該類主要用作資料傳輸（也就是充當dto，datatransferobject
如果實體類有行為，則該類主要用作業務處理。因為這些實體類要處理特殊的商業邏輯，比如說要不要資料校驗，要不要作些業務規則或工作流程，要不要持久儲存，要不要許可權控制，要不要啟動事務，要不要寫入跟蹤，要不要發布更改通知等等。此時，實體類既可以自身聚合相關的業務資料屬性，也可以純粹是個控制類，從而與資料傳輸類（dto）物件互動。
在一般的應用程式裡，二者常合二為一，即既有屬性，又有行為。這主要用於將多層執行於單一程序的程式。如需跨越程序邊界，該實體類就必須支援序列化，而只有資料才需要序列化，所以此時用dto當然更加合理。因為此時實體類的行為對於關係它的某些程序來講是毫無意義的，將這些行為排除掉，也符合物件導向的資訊隱藏原則。
上述的實體類，都是可以跨多層引用的。還有一種只用資料訪問層（dal）的實體類，其資料屬性主要與關聯式資料庫表列一一對應。甚至外來鍵都對應上了。這些類主查用於資料庫的增、刪、改、查，一般不用於資料傳輸。因oo的世界裡沒有關聯，而rdb確有，所以，這些實體類物件盡是些蹩腳的oo實現。真正的oo，應該用物件間的引用或者物件集合的引用來替換關聯。
總而言之，不管採用哪種實體類模型，主要取決於專案的時間、人力，還有開發習慣。從實用的角度來講，這幾種區別都不太大的。只是有些時候，採用某種形式的實體類模型會顯得比其它的形式更加優雅，如是而已。
建立實體類
下面直奔今天的主題 建立實體類 一點小插曲 接觸abp框架之前，一直都是使用的ef的dbfirst,在那種模式下，我們只要設計好資料庫，然後直接通過模板就生成了實體層，甚至都沒怎麼留意實體層的 是什麼樣子。現在要使用codefirst，就要反過來，先要寫 了，真有點不適應。好吧，為了學好abp，也要...
字典實體類 DictionaryEntry類
dictionaryentry類是乙個字典集合，主要包含的內容是鍵 值對。這種組合方式可以方便地定位資料，其中的 鍵 具備唯一性，類似於資料庫中的 id 乙個id對應一天記錄，而乙個鍵只對應乙個值。使用dictionaryenry類可以方便地設定和檢索資料。雖然被稱為字典集合，但dictionary...
C 反射實體類
using system using system.collections.generic using system.text using system.reflection namespace easysrcoreclass.component.utilcomponent 設定屬性值 public...