時間戳、復雜類型、GUID自增長
GUID自增長
GUID用於當主建那是好處多多，但是和int不同。EF不會自動識別第一個為類名+Id開頭或int類型字段 去設置自增長。尷尬的GUID怎么玩呢。。
Data Annation玩法
Fluent API 玩法
注：上面的設置好像沒什么用，至少我是沒跑起來。。。故而使用的是構造函數玩法。。。
時間戳
好處多多的東西啊，對於一些並發的業務來說建表的時候是一定要有這個的。但是某些原因….. 這就尷尬了 。。
最重要的一點是樂觀鎖，什么是樂觀鎖呢？
在並發的時候，A、B兩個線程同時拿到一條記錄然后進行更新再插入數據庫。這樣會導致A、B都成功了！對於一些搶單的來說這樣是不可以的。樂觀鎖則是在第一次更新的時候把時間戳也更新一下。另一個線程更新的時候會判斷當前的與表里的時間戳不一致的話。那就失敗了。
Fluent API 玩法
下面開始模擬並發，aContext先拿到更改一下字段值，緊接着bContext也拿到了更新了一字段值並保存。這時aContext再去保存
后面執行，bContext的成功保存！而aContext則報錯
假如像我這種尷尬的情況，表已經這樣了。應該怎么做樂觀鎖呢？可以使用 ConcurrencyCheck對某個唯一的字段進行注解，也可以達到控制並發的效果
復雜類型
隨着業務的擴展，表中的字段自然是越來越多，實體越來越膨脹。想想這會帶來什么后果？惡心的類，大多無用的返回值，結構不清晰。這些都是需我們去注意的。
這里假如項目第一版我們的用戶只有Name字段，但是在第二版需要加上地址。那簡單，直接在User類中直接加地址，但是上面說這樣是不好的。我們應該去 "擴展"。那也簡單，新建一個實體就是咯，然后在User中加入 屬性。但是！這樣會自動映射外建關系。這時我們就需要復雜類型了
復雜類型沒有ID //這里有些錯誤 [Table(xxx)] 是沒用的。因為不是創建新的表
在User類中進行擴展
搞定后，再Update-DataBase 一下
額。。。這就尷尬了。怎么還是在一個表中？之前是我理解錯了。我們代碼中的實體膨脹問題是解決了但是表中還是並沒有。這里我個人還是建議單弄一個表，把不屬於表的"核心屬性"放到擴展表中，這樣也算不錯吧。好歹代碼中不是這么惡心了