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