N層應用程序上的實體框架自我跟蹤實體

Question

這是一個通用的體系結構問題，希望對已經在最終應用中使用EF的人們有所幫助。

我們有一個典型的N層應用程序：

• WPF客戶端
• WCF服務
• EF STE DTO的
• EF數據層

該應用程序在加載期間（在用戶登錄的同時）加載所有已知的業務類型，然后按需加載非常大的“工作批次”，該批次大約為4-8Mg，由超過1.000個業務對象組成。 當我們完成加載此“批處理”時，我們將所有內容與先前加載的業務類型等鏈接起來。

最后，我們在內存中大約有2K-5K個業務對象都可以正確引用，因此我們可以在客戶端使用和濫用LINQ，我們還在客戶端上對所有這些對象進行一些復雜的數學運算，因此我們確實需要大圖。

當我們想要將更改保存到數據庫時，問題就來了。 有了如此大的對象圖，我們幾乎不想通過網絡再次發送所有內容。

考慮到到目前為止T4模板的復雜性，我當前不喜歡的方法是分離並附加更新中的所有內容。 我們基本上想更新一個給定的對象，將其與圖的其余部分分離，通過網絡發送，在WCF端進行更新，然后在客戶端再次進行附加。 主要問題是，當您要更新鏈接的對象時，假設您添加的對象具有對也要添加的對象的引用，然后又添加了對已修改的對象的引用，等等。這迫使許多客戶端代碼確保我們不這樣做。不要破壞任何東西。

所有這些操作都是通過生成的代碼完成的，因此我們正在談論每個模板200-800行的T4代碼。

我現在正在查看的是一種自定義STE序列化和反序列化的方法，這樣我就可以控制是否通過網絡發送了什么，並且能夠更新批處理，而不僅僅是一個STE。 檢查參考，查看這些參考是否未更改； 如果不是，則不進行序列化；如果是，則不進行序列化，只需將其附加到WCF端的上下文即可進行序列化和更新。

經過研究，我發現了該方法的兩種解決方案。

一種是編寫自定義DataContractSerializer。

第二個方法是通過更改由EF創建的STE模板並使用KnownTypeAttribute，而不是為每種引用類型生成它，而是讓它引用一種檢查對象的方法，並僅標記未更改的序列化引用。

• 有人遇到過這個問題嗎？
• 您使用了什么解決方案？
• 您到底遇到了什么問題？
• 維護創建的模板有多容易？

Answer 1

我不知道整個應用程序的設計，但是如果您通常將工作批加載到服務中，然后將其發送給客戶端以進行使用，則看起來服務層似乎是不必要的，您可以直接從數據庫加載數據將會獲得更好的性能）。 根據計算的復雜性，您還可以直接在數據庫中進行一些計算，您將再次獲得更好的性能。

您只保存部分圖表的方法是濫用STE概念。 STE的工作方式-您加載圖形，修改圖形並保存相同的圖形。 如果您想擁有一個較大的數據集以讀取並僅保存小塊，則最好加載要讀取的數據集，一旦決定更新一個塊，則僅再次加載該塊，然后對其進行修改並發送回去。

干擾內部STE行為是在某些轉角/意外情況下丟失某些更改的最佳方法。

順便說一句。 這種方式看起來像是一種將本地數據庫與全局數據庫同步的方案-我從未做過，但是在智能客戶端中很常見。