serializable，之前一直有使用，預設的實體類就會實現serializable介面，對具體原因一直不是很了解，同時如果沒有實現序列化，同樣沒什麼影響，什麼時候應該進行序列化操作呢？今天查了下資料，大致總結一下。
1、其實序列化，它是完整的儲存了某一狀態下的物件資訊，是乙個整體，而不是零散的！我在乙個ibm工程師的部落格裡面看到乙個說法，我感覺對於我理解序列化很有幫助，他說序列化的過程，就是乙個「freeze」的過程，它將乙個物件freeze住，然後進行儲存，等到再次需要的時候，再將這個物件de-freeze就可以立即使用。
2、而像int、long、boolean型別等，都是基本資料型別，資料庫裡面有與之對應的資料結構。從類宣告來看，我們以為的沒有進行序列化，其實是在宣告的各個不同變數的時候，由具體的資料型別幫助我們實現了序列化操作。所以就算我們不實現serializable依舊可以正常操作。
這時候，就又有乙個問題，既然實體類的變數都已經幫助我們實現了序列化，為什麼我們仍然要顯示的讓類實現serializable介面呢？
首先，序列化的目的有兩個，第乙個是便於儲存，第二個是便於傳輸。我們一般的實體類不需要程式設計師再次實現序列化的時候，請想兩個問題：第一：儲存**裡面，是否是有其相對應的資料結構？第二：這個實體類，是否需要遠端傳輸（或者兩個不同系統甚至是分布式模組之間的呼叫）？
如果有注意觀察的話，發現序列化操作用於儲存時，一般是對於nosql資料庫，而在使用nosql資料庫進行儲存時，用「freeze」這個說法來理解是再恰當不過了，請在nosql資料庫中，給我找出個varchar，int之類的資料結構出來？ 如果沒有，但我們又確實需要進行儲存，那麼，此時程式設計師再不將物件進行序列化，更待何時？
備註：如果有人開啟過serializable介面的原始碼，就會發現，這個介面其實是個空介面，那麼這個序列化操作，到底是由誰去實現了呢？其實，看一下介面的注釋說明就知道，當我們讓實體類實現serializable介面時，其實是在告訴jvm此類可被序列化，可被預設的序列化機制序列化。
然後，需要說明的是，當我們在實體類宣告實現serializable介面時，再次進行觀察，會發現這些類是需要被遠端呼叫的。也就是說需要或者可能需要被遠端呼叫，這就是序列化便於傳輸的用途。
建立實體類
下面直奔今天的主題 建立實體類 一點小插曲 接觸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...