首先，經典的三層架構形成的主要目的是什么？
無非就是划清表現層、業務邏輯層和數據層三者的關系。方便代碼維護升級。相互解耦和！
當任何一層有內部變動時，不牽扯其他層的代碼變動，這就是主要目的！
那么最近我總在思考一個問題：
DAL數據層是負責BLL邏輯層最終要執行的數據庫操作。
而涉及到BLL業務邏輯需要事務處理時，到底事務處理代碼是放到BLL層還是DAL層成了一個討論比較多的話題。
我在一個博客里看到有處理辦法是由BLL層創建一個固有的Tran對象來穿插所有事務操作。為每個DAL都創建Tran對象接手執行方法，接收BLL傳來的Tran對象，所有事務執行完畢后，由BLL來執行RollBack操作。 博客地址：http://www.cnblogs.com/yyl8781697/archive/2012/02/01/SqlTransaction.html
這樣做為整個項目帶來的好處就是BLL層不牽扯數據層，那么BLL拿到的Tran對象算什么？
每個DAL層都接受Tran對象是否增加了代碼量和維護成本呢？
每個DAL層都要判斷是立即執行還是Tran，到最后的RollBack是交給BLL層來提交還是其他方式。
我想了很久，我們分層的主要目的是什么，又談到文章開頭部分。
分層的中心思想就是解耦和，方便維護跟升級。那么現在出現的事務處理到底是直接在BLL層獲取Connection並在BLL內部執行所有Tran操作，還是獲取一個Tran對象貫通所有DAL操作，最后RollBack呢。
總覺得這樣做有點不倫不類！
所以最后我自己得出了一個自認為比較合適的方案。
那就是多寫一個“Tran（事務層）”，專門存放所有事務操作。這樣層次清晰，代碼責任划分明顯。也更方便維護。
這樣的好處有如下幾點：
1、BLL完全脫離任何跟DB相關的代碼，專心處理業務邏輯。
2、不影響DAL的簡單、單一數據庫處理代碼。
3、集中管理項目Tran事務操作部分。
胡言亂語這么多，也不知道大家能否理解我的想法，或者我這樣做是否正確呢？
特地厚臉皮放在首頁，讓大家都來討論一下，或者大家都有更好的方案來指點下我這個井底之蛙！ 見笑了！