交易：控制器vs服務

考慮一下我有一個控制器方法get（），它調用幾個使用數據庫的服務方法。交易：控制器vs服務

使整個控制器方法是事務性的還是隻是每個服務方法都是正確的？

在我看來，我們必須讓get（）事務，因爲它執行相關的操作。

謝謝！

2010-12-16 Andrey Minogin

我更喜歡只製作事務性的服務方法，這些方法需要是事務性的，並且控制不在控制器中的服務中的事務性。您可以創建一個服務方法，該方法使用其他服務方法，並使用spring事務在@Transactional註釋中使用傳播來管理事務。

@Transactional(propagation =...)

編輯

如果我有2種方法，例如saveUser（）和saveEmail（）（因爲我存儲在數據庫中的電子郵件，發送它們 - 就像一個隊列）我想創建我的服務方法saveUserAndSendEmail（用戶用戶），這將是事務性的。這個方法會調用saveUser和saveEmail（）中的每一個在@Repository組件中，因爲它們處理數據庫。因此，我會將它們放入@Repository組件中用於處理數據庫的方法，然後控制@Service組件中的事務性。然後，控制器只需要擔心在需要時提供數據和呼叫。但是我做了一個事務，因爲我不想在數據庫中提交更改，直到整個方法成功執行。

但這是我通常使用的風格，我並不是說這一定是要走的路。

來源

2010-12-16 16:21:45 Javi

它似乎是首選設計，但爲什麼？考慮我需要loadMenuItems（），loadUserInfo（），loadDocument（） - 很多方法。根據你我必須創建一個loadMenuItemsAndUserInfoAndDocument（）方法 - 可以嗎？ – 2010-12-16 16:23:35

@Andrey我沒有說過這是首選設計。這是我平常工作的方式，因爲我更喜歡控制器不需要知道事務管理。根據你的方法的名稱開始加載...如果他們只從數據庫中真實的，你爲什麼需要進行交易？ – Javi 2010-12-16 16:28:43

那麼，如果你有兩種方法：createUser（），sendEmail（）來自不同的服務（用戶和郵件）。而且你需要在一個transactionalal控制器中調用它們。你該怎麼辦？ – 2010-12-16 16:29:56

這完全取決於您，以及您如何解讀自己的業務邏輯。

Spring並不關心你把事務邊界放在哪裏，當然也不會限制你把它們放在你的DAO類上。

所以是的，將@Transactional添加到您的控制器方法是完全有效的。

來源

2010-12-16 16:20:47 skaffman

恕我直言，@Transactional在控制器從體系結構角度（MVC）沒有太多的意義。我的意思是，控制器不應該意識到持久層，並且您可能必須在您的控制器層不再存在的桌面應用程序中重用您的業務邏輯......我認爲事務性應該在@Service層中定義。 – 2010-12-16 23:35:55

交易：控制器vs服務

回答

相關問題