交易處理的層次問題

最近一直在想一個關於交易處理層次 的問題。平時我們在做J2EE應用的時候，習慣把應用分為三個邏輯層次，web層，業務層和持久層，比較經典的是持久層一般使用dao的設計方式。涉及到資料庫相關的交易處理時，很多人也就習慣於將交易處理代碼寫在dao這一個層次上，也就是持久層這個層次。這樣寫對於簡單一點的資料庫訪問沒有什麼問題，一旦實現複雜一點，牽涉到的業務處理比較繁雜一點時，這種在dao裡面處理事務的方法就有點力不從心了。

    打個比方，我一個dbDAO介面裡面有updateA和updateB兩個方法，這兩個方法中假設都會同時更新幾張表（這種情況很常見），這樣就會涉及到交易處理的問題，在updateA中，我們使用事務進行處理,在updateB中我們也謝了交易處理的語句。現在問題來了，如果一個業務處理要求，如果updateA成功時，更新updateB，如果失敗，那麼都需要復原，這樣的話，業務層調用了updateA成功提交之後，updateB卻失敗了，原來那個方法就沒有辦法復原。當然，我們可以在dao中增加兩個沒有交易處理的方法來調用，但是請仔細想想，這樣合適嗎？？？？？

  不過，你也可以將部分業務實現寫到dao中去，這樣也可以處理，但是這樣業務層和持久層就明顯含混不清，失去了分層的意義。

  因此我們想到把交易處理放到業務中去。原因很明顯，交易處理是業務處理的需要，理應隨業務的變化而變化，事務跟底層持久化毫不相干，也就是說dao層根本不應該出現交易處理的代碼。但是如果我們將資料庫交易處理代碼放到業務層之後，明顯感覺有點bad smell的味道。所以我們可以利用AOP架構，例如，SPring,將交易處理單獨提煉出來，對業務層進行事務控制。而DAO層由於接收交易處理的任務，所以任何業務方法都可以放心調用，只有在需要事務的時候對業務方法添加事務即可。