實體框架/數據庫設計 - 更新數據但保留以前數據的鏈接

我已經通過一個實際的例子學習了ASP.Net和Entity Framework 4。爲了試用這個，我使用User的例子發送設備Repair。他們在線創建一個賬戶，添加一組Details（地址，電話，傳真等），並在線創建退貨單（RMA）。實體框架/數據庫設計 - 更新數據但保留以前數據的鏈接

我正在努力的概念是將Details分配給Returns。 A Return有一套Details，一個用於聯繫，交付和計費。這些可以是Detail表的外鍵，如下所示。

問題是，如果User在線編輯它們的Details，它將更新在Return上使用的Details。這不是理想的行爲。 Return應使用在創建時可用的Details。

問題是，你如何使實體框架創建一個新的Detail對象，而不是更新現有的對象。也就是說，如果用戶用新的郵政編碼更新Detail 23，則Detail 23不被更改，而是創建新的Detail（即45）。 Detail 23從User中刪除，並且新的Detail 45被添加到User。雖然使用Detail 23的現有RMA不受影響，但如果您查詢RMA，則會得到在創建時提供的詳細信息的含義。

如果在閱讀這個問題，你認爲這個概念是有缺陷的，取而代之的是DB進行不同的設計應（即複製在RMA表Detail數據列，或添加在複合鍵的形式Detail表中創建修訂歷史）。我也很樂意聽那些明智的話。

ERD of RMA System

來源

2012-06-10 JonWillis

你應該問自己一個問題：誰擁有23號細節？它應該是用戶或RMA，而不是兩者。如果它是RMA，它將代表適用於特定RMA的用戶詳細信息，如果是用戶，它將代表獨立於任何RMA的用戶詳細信息。 –

UserID引用創建RMA的用戶。然而，可能有幾個人可以看到RMA，即需要查看它的工作人員。 – JonWillis

如果你有一個是基本的CRUD的領域之外複雜的數據編輯的規則，那麼你基本上有兩種選擇實體框架。

放棄簡單的數據綁定，並將您的特殊處理建立到位於GUI和數據層（EF）之間的業務規則層。
放棄精簡EF層的簡單性，並將特殊數據處理規則放入存儲過程，然後將EF模型中的CRUD過程設置爲您定義的存儲過程。

無論哪種方式，你是一個妥協，因爲沒有ORM，EF或otherise，可容納兩個「無代碼」數據綁定和不平凡的CRUD處理。選擇適合您的項目的方法並推薦最佳方案。有些人沒有數據綁定就無法生存，有些人無法生存。有些愛儲存過程和其他人不喜歡它們。

來源

2012-06-10 23:30:09

除了使用存儲過程的建議之外，都適用，不建議使用。使用DDD可以解決該情況。 –

我認爲我更喜歡選項一。我假設這意味着當用戶更新「詳細信息」時，點擊保存。在代碼中，我從用戶的詳細信息集合中刪除當前的「詳細信息」，然後使用提供的新信息創建新的詳細信息，將詳細信息添加到詳細信息收集並保存。這是否會使現有細節保持不變，或者將刪除用戶的細節，潛在地刪除細節。 – JonWillis

@JonWillis - 我想你可能需要更仔細地看看「刪除」細節。如果你開始刪除對象，你至少會破壞FK關係，而你的聲明性參照完整性可能不允許 - 或實際刪除記錄 - 你不打算這樣做。你想添加新的細節，這是非常確定的。問題是你如何處理舊的細節。這取決於數據庫的結構。我認爲你的意思可能是UserDetail，而不是細節正在被刪除/替換。 –

實體框架/數據庫設計 - 更新數據但保留以前數據的鏈接

回答

相關問題