知識星球最近在做公司的專案的時候，開始把部分程式遷移到EF Core，然後有了一些感觸，趁著還沒忘卻，還是先記錄下來。
EF Core還在成長中，我寫這個的時候，版本是2.2。如果對著已有的EF 5/6來說，還有很多功能要迎頭趕上的，所以這個也是為什麼在.net core 3的標準中，計劃要支援EF 6（這個其實是一次性買賣），就是想讓大家可以先把.net Core (EF6)用起來，讓EF Core先緩口氣，等它成長足夠了，再遷移到.net Core (EF Core)這樣的組合。
即便如此，現在版本的EF Core已經有好多不少的閃亮之處（當然也有一些會因為自己沒學好而誤會了它的坑）。不論是閃亮點，還是坑，我有時間的話，會緩緩道來。
Shadow Properties這個特性很好，值得先拿出來說一下。但是部落格本來就不適宜寫得長，不然就不適合碎片閱讀。所以我會把它分開來寫。而且我還可能會比較囉嗦，有騙字數的嫌疑。
Shadow properties are properties that are not defined in your .NET entity class but are defined for that entity type in the EF Core model. The value and state of these properties is maintained purely in the Change Tracker. (https://docs.microsoft.com/en-us/ef/core/modeling/shadow-properties)
簡單地說，隱藏屬性 (Shadow Properties)，就是那些邏輯設計裡面沒有的，但是物理設計裡面卻要有的屬性。邏輯設計 vs. 物理設計，是做面向物件程式設計的攻城獅，都需要面對的問題。例如，那些資料庫自增長的ID，審計類欄位，還有例如做資料庫訂閱所需要的時間戳等等。很繞口，讓我說人話，就是我們的business class（業務類），是不會包括那些只對照某資料庫，或者中介軟體才冒出來的神馬ID之類的屬性，而我們卻可以在EF Core層面，搞定這些ID的安置方式，而不需要另外再弄一個新的EF class。
有了這個，我們就可以保持邏輯設計的乾凈，也可以省了再去多弄一個EF Class。或者乾脆就著EF Class來細細搗弄（為了繼續保持邏輯層的乾凈）。後述的兩種手法，在我們靈活運用EF 5/6的時候，已經屢見不鮮了。
簡單舉個幾個慄子（邊幅所限，本篇先來一個個簡單的，後面的繼續舉拖沓的慄子，繼續騙字數）。例如，我們會在資料庫有一些 LastUpdateBy （記錄最後修改者/兼顧新增此記錄建立者）、LastUpdateDate（記錄最後改動的日期和時間）、CreatedDate（新增此記錄的日期和時間）等等，提供簡單審計記錄功能的欄位。但是，我們的Class裡面，真心不想要這些屬性。這個時候，我們可以繼續保持原有business class不變。而在我們的DBContext class的OnModuleCreating方法中，針對某個需要有上述審計欄位的Entity，加上這些Shadow Properties。下麵的程式碼片段的例子，只支援UpdateDate和UpdateBy，CreateDate請自行腦補哈(Tips: EntityState.Added 狀態下才更新此屬性的值)。
很簡單對吧？只需要偷偷地在自己的DBContext裡面搗弄一下，根本不需要讓上層建築知道那麼多，我們就支援了僅在資料表裡面才有的審計類欄位。
接下來，下一篇，會舉一個更囉嗦的慄子。解釋一下，為什麼我們的business class，不應該有那些由於物理設計（落地選型）所帶出來的各式各樣的神馬ID，以及怎麼用Shadow Properties來支援。但是因為這個涉及到asp.net core web api的相應改動，所以值得另開一個帖子來騙字數了。
原文地址:
https://www.cnblogs.com/fatkent/p/EFCore_ShadowProperties_1.html
