XAF中XPO與EFCore的探討_ZenDei技術網路在線

### 前言首先拋出一個問題，在XAF項目中，我們現在可不可以選擇EFCore？每個人可能都有自己的答案，這也沒有什麼標準答案。下麵是我的個人看法，在剛接觸XAF時，如何選擇ORM，我也是猶豫了許久，最終選擇了XPO，主要基於以下幾點考慮 1.XPO是DEV的產品，支持力度及傾向性要比EFCore ...

前言

首先拋出一個問題，在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版的軟刪除分享給大家。