前言
首先丟擲一個問題，在XAF專案中，我們現在可不可以選擇EFCore？每個人可能都有自己的答案，這也沒有什麼標準答案。下面是我的個人看法，在剛接觸XAF時，如何選擇ORM，我也是猶豫了許久，最終選擇了XPO，主要基於以下幾點考慮
1.XPO是DEV的產品，支援力度及傾向性要比EFCore高
2.XPO是XAF最開始支援的ORM，XAF中的各個模組對XPO的支援更好（有個別模組不支援EFCore）
3.在XAF的社群中，關於XPO的各個方面的問題都有相應的解答，相對來說比EFCore更有優勢
我想應該也有部分小夥伴可能與我的考慮是一致的，但為啥要丟擲這個問題呢，是因為XAF的一篇文章（https://docs.devexpress.com/eXpressAppFramework/404186/why-we-recommend-ef-core-over-xpo）
DEV建議在新的XAF專案中優先採用EFCore，文章中對比了XPO與EFCore，總體來說它們各有特點，也有很多相似之處。DEV建議優先選擇EFCore的原因可能與XPO一直處於維護狀態有關，此外，EFCore的發展勢頭也越來越強勁，在XAF中使用EFCore已成為大勢所趨。但是將XPO遷移到EFCore並不容易，由於XAF最初的ORM是XPO，因此某些功能是基於XPO或傾向於XPO，所以在EFCore上的效果可能會有所不同。
探討
雖然XPO和EFCore在語法上有許多不同，但在思想上基本一致。大部分XPO中的特性都被EFCore支援，但是有一個EFCore沒有的特性，即NestedUnitOfWork，在EFCore中對應NestedDbContext，但EFCore沒有。XAF利用XPO的這個特性構建了XPNestedObjectSpace，使父子表（或主從表）之間的操作更加自然和靈活。
由於EFCore沒有這個特性，因此使用起來與XPO的操作不一致，甚至會給人一種不可接受的感覺。下面透過刨析它們內部的原理，來講解它們行為不一致的原因，同時不可接受的地方，透過了解後是否可以接受它。
首先講一下，在XPO中習以為常的功能，在EFCore中卻會出現不一樣的行為。這主要出現在父子表中，或者說聚合實體中，這裡假設一個場景，使用者表（User）中包含一個使用者標記(UserTag)列表（Tags），它是聚合的（Aggregated），這是一個一對多的關係。當我們新建User後，再向Tags列表中新增UserTag時，在EFCore下，會自動儲存User，而在XPO中不會有這樣的操作，這樣會造成一個問題，如果此時，我想放棄當前新建的User，我把User關閉後，列表中會多一條剛才放棄的User，這種現象在XPO中是沒有的，為什麼會有這樣不一致的行為呢。這就是前面提到的XPNestedObjectSpace，而EFCore沒有這樣的一個實現。
這裡要引出XPO中的Session，它與EFCore的DbContext是對應的（確切的說與UnitOfWork更像），Session有多個子類如UnitOfWork，NestedUnitOfWork，ExplicitUnitOfWork，透過名稱我們也可以瞭解它們的用途，我們平時在建立BO類時，都要有一個包含Session引數的建構函式，這裡的Session一般都是它的子類UnitOfWork，Session中的事務比較簡單，我們在呼叫BO物件中的Save方法時，就會直接提交到資料庫。UnitOfWork又多了一層，呼叫BO物件中的Save方法時，並不會立即提交到資料庫，我們需要呼叫UnitOfWork中的CommitChanges方法，它會將工作單元中的BO物件一併提交到資料庫，而ExplicitUnitOfWork會啟用一個顯式事務(也稱作資料庫級事務)，我們透過BeginTransaction方法開啟事務，透過CommitTransaction方法提交事務，在沒有提交之前，你可以多次呼叫CommitChanges方法，如果其中一個提交出現異常或其它原因放棄提交，你可以透過RollbackTransaction方法回滾事務，這樣就可以將之前的所有提交都進行回滾。
NestedUnitOfWork是我們需要重點關注的，它就是巢狀工作單元，你也可以把它看作是UnitOfWork的子工作單元，它有一個好處就是，它可以直接訪問到父級中的物件也就UnitOfWork中的物件，同時它提交時，並不會直接提交到資料庫，而是等待父級的UnitOfWork一起提交，它們的提交是放在同一事務中的，如果NestedUnitOfWork不提交，而父級UnitOfWork進行了提交，此時提交的內容不會包含NestedUnitOfWork中的物件。
以上NestedUnitOfWork的特點帶來許多好處，如可以使父子表間的編輯變的簡單，父表提交時，可以一起提交子表，父表放棄後，子表也會放棄，子表也可以隨時單獨放棄等等，當與XAF的主從檢視結合時，就會有很不錯的操作體驗。
如果沒有NestedUnitOfWork，將會發生什麼呢，首先兩個UnitOfWork是不能直接通訊的，其中一個UnitOfWork建立的物件，如果另一個UnitOfWork想訪問，第一個UnitOfWork需要先提交到資料庫，第二個UnitOfWork再從資料庫中讀取，而NestedUnitOfWork可以直接透過GetObject方法訪問到父級UnitOfWork中的物件，這樣就減少了一次提交與讀取的過程。
再回到前面建立User的示例，由於UserTag與User是聚合關係，也就是UserTag只屬於一個User，同時UserTag中的User外來鍵還不能為空，也就是說UserTag脫離User，它本身就沒有意義，相當於訂單與訂單明細的關係。在這種情況下，我們在User中新增UserTag時，UserTag首先需要一個User，而如果此時User也是新建的，並且它們分別在不同的UnitOfWork中時（在XAF的主從檢視中，如果新建從表資料，XAF會單獨建立一個ObjectSpace，也就是當前User與UserTag會在不同的ObjectSpace中），我們能想到的就是儲存User，在UserTag所在的UnitOfWork中從資料庫中讀取User。
看到這裡的小夥伴應該明白了，XAF為什麼會在新增UserTag時需要儲存User了吧。我們剛才談到的是聚合關係，如果不是聚合的一對多關係是否會自動儲存父級呢，不會的，因為不是聚合，那它的外來鍵可以為空，也就是UserTag的User外來鍵可以為空，這樣在新建時，可以不必事先獲取父級，那也就沒必要儲存父級了。
前面講的都是新建的User，如果是已存在的User，也就是從列表中開啟的User，如果在User中新增UserTag會不會自動儲存呢，也不會，因為User已存在於資料庫中，在UserTag的UnitOfWork中就可以從資料庫中獲取到User，這樣也沒有必要儲存User。如果仔細觀察，在沒有修改User的情況下，新增UserTag，儲存按鈕還是處於禁用狀態，這是由於它們處在不同的UnitOfWork中互不干擾。
在EFCore中，將上面的UnitOfWork替換為DbContext，也就知道了為什麼EFCore會出現與XPO不一致的行為了，這裡的關鍵點就是NestedUnitOfWork，而EFCore沒有對應的實現，那是不是EFCore就不是一個好的選擇呢，我倒覺得不是，透過上面的示例，我們可以看到，除了在新建具有聚合關係的物件時，會出現與XPO不一致的行為，其它的地方與XPO基本保持一致。
隨手建立，隨手放棄，可能是我們日常測試時經常操作的，但是在上線執行時，日常操作會有相關的約束，不會頻繁出現這樣的行為，再加上XAF自動儲存時也會進行資料校驗，校驗不透過也是無法進行自動儲存的，同時由於Blazor自身的特點，對於一些需要長時間錄入的頁面，我們還需要自己加入自動儲存的功能，已防止錄入資料的丟失。
我曾經試圖去解決這個問題，為EFCore建立一個EFCoreNestedObjectSpace，EFCoreNestedObjectSpace直接採用父級的DbContext，這樣可以實現在一個事務中提交，但最後發現解決一個問題，引出一堆問題，最後還是放棄了，在底層沒有支援的情況下，是無法實現與XPO相似效果的。
在瞭解了上面的內容後，我們發現，XAF中使用EFCore，與XPO相比出現的不一致行為，也不這麼神秘了。但這不是全部，EFCore與XPO還是有很多不同的，如果習慣了XPO，你會發現在XPO中有許多預設行為，在EFCore中需要手動的配置，比如延遲刪除、樂觀併發等，這些需要注意。
關於XPO中的延遲刪除（DeferredDeletionAttribute），有些小夥伴會把它當成軟刪除（SoftDelete），這是不正確的，它與軟刪除還是不一樣的，雖然延遲刪除不會刪除記錄，但它會清除記錄中的外來鍵，它的存在是為了解決XPO刪除記錄時，由於資料庫的外來鍵約束造成的失敗，但本質還是刪除，只是保留了記錄，事後需要自己清理。當你試圖恢復延遲刪除的記錄，你會發現記錄與其它記錄的關係沒有了，這也是為什麼不能用作軟刪除的原因。EFCore中實現軟刪除比較簡單，使用HasQueryFilter配置實體就能實現軟刪除的功能，事後我會在XAF中實現一個EFCore版的軟刪除分享給大家。
最後
隨著XAF中使用EFCore的深入，可能還會發現與XPO的不同，或出現一些無法解決的問題，我都會更新到文章中。當我完全切換到EFCore時，可能今後就要遠離XPO了，有些不捨，但總要去面對，新技術總會取代舊的技術。