爲什麼儲存庫不能保存事務邏輯？

有一個設計良好的領域，聚合不相互引用，定義良好的邊界和具有良好定義的對象引用的聚合對象，爲什麼在庫中存儲事務邏輯是不好的做法（爲每個領域對象創建一個存儲庫）？爲什麼儲存庫不能保存事務邏輯？

在回答UoW模式之前，請考慮這個問題UoW limitation。

來源

2013-12-17 Geo C.

你可以發表你的意思是「在倉庫裏面有事務邏輯」嗎？資源庫中的給定方法是否包含整個業務事務，您是否會調用資源庫上的單獨方法來啓動和提交事務...？ – guillaume31

因爲典型的事務通常跨越多個存儲庫。當你的股票賣給你想要的，在同一交易產品，以

減量元素的數量（StockRepository）
創建訂單（OrderRepository）
創建裝運（ShipmentRepository）

而你真的希望所有這些成功或失敗。

來源

2013-12-17 17:25:44

存儲庫無法像引用域中的對象一樣持有對其他存儲庫的引用嗎？所以交易可以駐留在這一層？如果不是交易邏輯應該放在哪裏？ UoW正在限制我進行簡單的交易，如鏈接問題。我應該爲這些交易的目的而製作一個服務層嗎？ –

爲了交易的目的，並實現您的業務邏輯。當您銷售10種產品時，您希望根據產品的重量和體積創建包含10個訂單行的單個訂單，並根據需要創建儘可能多的貨件，並提醒您新庫存量低於一定限制等。。這是需要實施的業務邏輯，並且不屬於所涉及的三個存儲庫中的任何一個。存儲庫的全部要點是將持久性邏輯與業務邏輯分離。 –

在您的示例中orderLine是持有產品和裝運參考的根。 oerderLineRepository不能引用productRepository和shipmentRepository嗎？在oderLineRepository中創建一個事務，其中startsTransaction（）從這三個存儲庫中調用簡單的CRUD並在一切正常後提交查詢？ –

即使每次交易的情況下，一個聚合，代碼塊通常是這樣的：

Order order = orderRepository.findBy(orderId);(1) 
order.doSomething(); 
orderRepository.store(order);//or omitted with uow

Techonically，如何實現資源庫中的事務邏輯和鎖定時化策略的一些步驟是倉庫外面？

來源

2013-12-19 01:09:13 Hippoom

因爲它打破了單一責任原則。存儲庫是聚合根集合的提供者，而不是事務協調者。此外，他們的實現駐留在持久層中，這意味着他們的視野太低，甚至不瞭解業務事務等重大問題。

來源

2013-12-19 09:33:17 guillaume31

:)你如何堅持你的對象？實際上，他們也需要數據庫層的協調。他們的視野並不低，你需要在數據庫中映射狀態，這樣你就可以檢索consitent對象。我特指數據庫事務（這也需要一致性）。出於一致性的原因，你甚至可以在數據庫端爲複雜的設計/邏輯做觸發器（我不得不這樣做一個數據庫多態關聯wrokaround）。這個例子只是爲了顯示數據庫還需要與域相關的整合。 –

我不會通過存儲庫保存我的對象。我從存儲庫公開的集合中添加或刪除對象，或修改它們，但這些更改不會立即保留。應用層服務知道正在進行的用例的狀態，可以決定*何時保留。 *如何堅持也不是由您的存儲庫實現，但通常由您的ORM實現。即使沒有ORM，我也會有一個特定的適配器對象，從邏輯/業務提交轉換爲物理提交（可以是數據庫事務提交或其他）。分開的責任，分開的對象。 – guillaume31

我認爲你在混淆工廠和知識庫。存儲庫是一個從存儲技術中抽象模型的層。即使使用ORM，也應該從存儲庫中調用映射器（誰知道以後可能會轉到非關係數據庫）。 –

爲什麼儲存庫不能保存事務邏輯？

回答

相關問題