使用EF/Code First/Repository Pattern/Table Per Type（TPT）時的良好編程原則？

Question

只是好奇。

說我有一個基本實體，我使用Table Per Type方法從它派生出約10個不同的子實體。我也有一個通用的存儲庫，可以從這些子實體中獲取數據。我最終希望將每個子實體映射到一個單獨的視圖模型，並將每個視圖模型鏈接到我網站上的它自己的網格（JqGrid），每個網格都有自己的Create，Read，Update，Delete方法。我可以做所有這些，但我不確定在保持代碼最小的情況下，採取什麼正確的方法。

現在，我在每個視圖模型中定義了每個字段（來自父級和子級實體）。有一個「父」視圖模型，然後從它派生子視圖模型以模仿實體的繼承結構是否更好？我不這麼認爲......在視圖模型中具有繼承性對我來說沒有多大意義。

此外，我真的不想重複每個網格的CRUD操作。這被認爲是良好的做法？在這種情況下，每個視圖模型是否應該有自己的一套CRUD操作？

以'讀'爲例。我基本上基於每個網格的視圖模型的ID（鍵）字段返回JSON數據。而且由於所有網格都有這個ID列（父實體的一部分），我是否應該只有一個函數來處理所有的網格？我應該使用反射？我應該使用父/子實體的多態屬性嗎？

或者爲每個網格保留這些操作是否更好？

嗯..

Answer 1

這取決於。

在所有規則的基礎上，我會說：保持簡單，不要重複自己。

一些評論：

說我有一個基本的實體，我從它使用的表每種類型的方法來提取約10個不同的子 實體。

僅作爲附註：您知道TPT的性能不佳（至少對於EF < 5），對吧？特別是如果表格可能很大，或者你有很深的繼承層次結構（派生實體派生的實體...等等），那麼要特別注意。

我最終希望映射每個子實體到一個單獨的視圖 模型

這在我看來是個好主意，獨自爲你可能會應用到的ViewModels爲每個派生實體可能不同的驗證規則。

是更好地有一個「父」視圖模型，然後從它爲了模仿 實體的繼承結構推導孩子 視圖模型？

到模仿實體的繼承不是我認爲的原因。但是，如果您有例如查看基本模型屬性的驗證規則，並且它們適用於所有派生實體，爲什麼不將這些規則保存在一個位置 - 就像基礎ViewModel一樣。否則，你必須在每個派生的ViewModel中重複它們。

在這個 的情況下，每個視圖模型應該有自己的一套CRUD操作嗎？

如果派生實體是「平」（只有標量的屬性，沒有導航屬性），你只需要類似：

Read: context.BaseEntities.OfType<T>().Where(...)... 
Add: context.BaseEntities.Add(T entity); 
Delete: context.BaseEntities.Remove(T entity); 
Update: context.Entry(object o).State = EntityState.Modified; 

所有這些方法對基類和派生實體合作。你爲什麼要爲每個實體單獨創建這樣的方法？儘管在更復雜的情況下，您可能需要單獨的方法，例如，如果派生實體編號7具有另一個實體的導航屬性，並且您對該實體的視圖確實允許將關係更改爲另一個實體。所以，這取決於。我不會從重複所有相同的方法開始，而是稍後在看到我需要特殊處理時重構（除非可能從一開始就預見到在項目演變期間的某個時間點期待特殊處理）。

我基本上根據每個網格的 視圖模型的ID（鍵）字段返回JSON數據。並且由於所有網格都將具有此ID列 （父實體的一部分），我是否應該只有一個函數 爲所有網格處理此問題？

在存儲庫/服務方面，是的，如果只爲每個派生實體加載標量屬性。如果你需要派生實體7的導航屬性，你可能需要一些特殊的東西（可能是Include）。將數據投影到ViewModels中可能對每個實體都是特定的，因爲每個實體都有單獨的ViewModel。

我應該使用反射？

WTF？爲什麼？最好不要。

我應該利用父/子 實體的多態屬性嗎？

??? （< - 這應該是一個「困惑」 - 圖釋）