解決Entity Framework中大資料模型問題的技巧

Entity Framework的開發領導Srikanth Mandadi稱這個包含兩部分內容的文章為“解決Entity Framework中的大資料模型問題”，但很明顯它的含義為“使用一些技巧”來解決這些問題。該文章首先談到了無論對任何應用來說，期望的實體數量在50到100之間。超出這個範圍會導致編輯器無法使用。

Entity Framework有一些嚴重的效能問題。例如，每次使用一個新的連接字串時，針對整個資料模型的基於XML的中繼資料都會被載入到記憶體中。如果你有一些共用通用資料模型的小型應用，那麼向其中任何一個增加新的實體都會導致所有應用變慢。從本質上來說，這種限制使得我們無法將Entity Framework的資料模型放到共用庫中。

視圖的產生是Entity Framework設計上的另一個敗筆之處。Srikanth Mandadi解釋到：

當查詢或是SaveChanges第一次發生時，這個過程就開始了。檢視窗產生步驟的效能不僅取決於模型的大小，還與模型之間的聯絡有關。如果兩個實體通過一個繼承鏈或是Association串連起來，我們就稱其為串連的。與此類似，如果兩張表通過一個外鍵串連起來，我們也稱其為串連的。隨著實體和Schema中表的串連數量的增長，檢視窗產生的代價就越來越大了。

為瞭解決這些問題，Srikanth Mandadi建議將大的資料模型劃分為小的子集。有兩種方式可以做到這一點，但感覺都不怎麼樣。

第一種僅僅是使用完全獨立的子集。如果兩個或多個子集都需要某張表，那麼就為他們分別建立獨立的實體。這種方式導致跨子集的直接調用無法實現，也容易導致實體的過度膨脹。

另一種方式是“使用”Schema中的文法。IDE不支援這麼做，需要我們手工編輯XML以說明資料庫需要使用另一個資料模型中的實體。除了手工編輯XML的痛苦外，它只能建立單向的串連。如果資料模型A使用了資料模型B中的實體，那麼後者將無法引用前者。

你可以在ADO.NET團隊的部落格上閱讀該文章第一部分和第二部分的所有內容。