最近在做公司的項目的時候，開始把部分程序遷移到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

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的Shadow Properties之美（一）【Microsoft Entity Framework Core随笔】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。