我計劃創建一個具有以下層的應用程序，并使用 Entity Framework 作為我的 ORM：介紹：與我的問題無關。業務：在這一層我打算只使用 DTO 對象。我想讓我的業務層與任何數據庫實現細節分開，因此與實體的所有交互都在 DAL 層中完成。DAL：在這一層中，我計劃擁有所有實體框架代碼和實體。我將介紹可由業務層調用的存儲庫。這些存儲庫期望 DTO 對象作為輸入，并返回 DTO 對象作為輸出。DTO和實體之間的映射是在這一層完成的。我看了很多在線教程和與實體框架相關的文章，并遇到了DbContextScope項目，它似乎是控制“業務事務”并確保提交或回滾所有相關更改的非常好的解決方案。請參閱 GitHub：https ://github.com/mehdime/DbContextScope該 GitHub 存儲庫中的演示包含一個在數據庫中創建新實體的場景。當我嘗試將該場景映射到我的圖層時，它似乎是這樣的：業務：為要存儲的實體創建具有屬性值的 DTO。在傳遞 DTO 的 DAL 層中創建新的 DbContextScope 和調用存儲庫。DAL：存儲庫將 DTO 映射到實體并將其添加到實體框架的 DbContext 中。業務：在DbContextScope上調用 SaveChanges() 方法，后者又在 Entity Framework 的 DbContext 上調用 SaveChanges()。在演示中，所存儲實體的 ID 在創建 DTO 時已知。但是，我正在尋找一種方法來確定在業務層中調用 DbContextScope 上的 SaveChanges() 方法后由 EF 自動分配的 ID。由于此時我處于業務層，我無法再訪問該實體，因此我無法再訪問該實體的 ID 屬性。我想我只能通過查詢數據庫中剛剛創建的記錄來確定 ID，但這只有在原始 DTO 包含一些我可以用來查詢數據庫的唯一標識符時才有可能。但是，如果我的 DTO 中沒有可用于查詢的唯一值怎么辦？關于如何解決這個問題的任何建議，或者您是否推薦我的圖層的替代方法？（例如，也在業務層中使用實體——盡管這聽起來是錯誤的做法）
1 回答
森欄
TA貢獻1810條經驗 獲得超5個贊
我盡可能使用 Mehdime 的上下文范圍，因為我發現它是一個工作單元的出色實現。我同意卡米洛關于不必要的分離的評論。如果 EF 被信任用作您的 DAL，那么它應該被信任按設計工作，以便您可以完全利用它。
在我的例子中，我的控制器管理 DbContextScope，我將存儲庫模式與我的實體的 DDD 設計結合使用。存儲庫充當與 DbContextLocator 作用域和定位的上下文交互的看門人。在創建實體時，存儲庫充當帶有“Create{X}”方法的工廠，其中 {X} 代表實體。這確保提供了創建實體所需的所有必需信息，并且實體在返回之前與 DbContext 相關聯，從而保證實體始終處于有效狀態。這意味著調用上下文范圍的 SaveChanges 時，綁定服務會自動為實體分配 ID。ViewModels / DTOs 是控制器返回給消費者的東西。您還可以選擇在 DbContextScope 的邊界內調用 DbContext 的 SaveChanges，這也會在上下文范圍 SaveChanges 之前顯示 ID。當您想要為松散耦合的實體獲取 ID 時，這更像是一種非常極端的情況。（無 FK/映射關系）存儲庫還為“刪除”代碼提供服務，以確保管理所有相關實體、規則等。雖然編輯實體屬于實體本身的 DDD 方法。確保所有相關實體、規則等都得到管理的代碼。雖然編輯實體屬于實體本身的 DDD 方法。確保所有相關實體、規則等都得到管理的代碼。雖然編輯實體屬于實體本身的 DDD 方法。
可能有一個更純粹的論點，即這種將域或 EF 特定問題的細節“泄漏”到控制器中，但我個人的觀點是，在服務層的有界上下文范圍內“信任”實體和 EF 的好處遠遠大于一切。它更簡單，并且允許您在代碼中有很大的靈活性，而不需要傳播近乎重復的方法來為消費者提供過濾數據，或復雜的過濾邏輯來從服務層“隱藏”EF。我遵循的基本規則是實體永遠不會在其上下文范圍的邊界之外返回。（無需分離/重新附加，只需選擇到 ViewModels，并根據傳入的視圖模型/參數管理實體上的創建/更新/刪除。）
如果您可以提供更具體的問題/示例，請隨時添加一些代碼概述您看到這些問題的地方。
- 1 回答
- 0 關注
- 135 瀏覽
添加回答
舉報
0/150
提交
取消