除了關系型數據庫（企業級應用主要的數據持久工具）之外，企業級應用還需要其他的方式進行持久層操作。比如，數據保存在文件中、數據來自或者流向遠程的其
他服務等。這樣持久層的操作就會有3——5種之多（還分有事務管理支持的和沒有事物管理支持的）。
怎么對這么多的操作進行有效的管理，怎么才能使持久層的變更只
限定在持久層的范圍內，怎么才能實現業務邏輯開發人員在開發上不必具有很多的持久層框架經驗（注1），還有就是怎樣實現既可以利用強制和工具輔助的方式使一個新人能夠開發出跟掌握持
久層開發的精髓的核心開發人員同樣質量的代碼（注2）又可以讓老手開發起來非常快捷（熟練工種），更重要的是在業務邏
輯方面物質化、代碼化積累公司的業界開發經驗，這就是我們下面要討論的問題。
我認為，要想實現持久層的修改（注3）與業務邏輯層分離。還要最大可能的把公用的東西抽象出來，最大可能的為培養業務專精人員提供基礎，就必須
要有一個機制，實現把持久層的任務交給持久層去作。
這是什么意思呢？
就是在系統基礎架構上，實現業務邏輯層和持久層的明顯松耦合（業務邏輯層根本不必知道持久層到底是什么介質和實現方式）。
但是作為業務邏輯層的對象，數據的持久化操作是它所不能避免的東西，也就是說，它不可避免的會和持久層打交道。
那么怎樣在代碼的級別實現和持久層打交道還不跟持久層相關呢？
這就是要在下面給出的總體設計。在這里簡單的介紹一下用到了三個技巧，一個是
IOC，一個是
Command模式，還有一個就是CallBack的概念。
IOC就是著名的好萊塢模式——你不用來找我，我會自己去找你的，而CallBack通俗一點說就是“你要做什么，你告訴我，到時候我會通知你，并把你想要的東西帶來的”。
業務邏輯對象不可避免的要對持久層進行操作，但是它對持久層的操作本身可以抽象成為一個Command對象，由注入到業務邏輯對象中的DAO來負責操作。說通俗點兒就是
說，對業務邏輯對象（BO）而言它是把一個任務說明書（CommandCallBack）給了一個它自己都不知道是從哪里來的叫做DAO的家伙（IOC），然后跟他說：
“你拿著它，按它的指示去把這事兒給辦了吧。”；業務邏輯對象知道“這事兒”是什么事兒，因為任務說明書是有名稱的，但是至于任務說明書的內容，它就不清
楚了。具體的事情DAO和任務說明書清楚，但是業務邏輯對象只是一個交接。換句話就是說，通過這么一個交接手續，把持久層的東西還給持久層了。業務邏輯對
象只想知道“這事兒”辦完的結果，事實上本來就應該這樣。
整體設計上面，涉及到了幾個持久層開發的基本的技巧，除了IOC、CallBack之外，還有DAO和容器管理。
DAO的模式其實也不是什么新鮮的搖滾Rock'n'Roll了，企業級應用要的就不是新鮮的東西（注4）。這個方式里面用的DAO是通用型的DAO，通
用型的DAO的優點就是接口統一，框架比較容易理解。但是缺點也十分明顯，那就是它本身的靈活性是值得懷疑的，JDBC就是一個統一的接口，結果呢，直接
用它就會導致SQL遍布代碼，這本身就增加了管理的復雜度，本來就是來封裝持久層的，結果跟沒封裝沒有區別，那么這個工作就是值得懷疑的。非通用型的
DAO倒是可以解決這個問題，但是非通用型的DAO就太靈活了，沒有辦法對它進行良好的封裝，而且對于建筑在持久層的基礎之上的業務邏輯層架構而言，這種
靈活性導致了只能對業務邏輯操作進行粗放式的封裝，可重用的東西相對沒有使用通用型DAO的時候多了。還有就是非通用型DAO的開發上面想要實現代碼重用
也是比較麻煩的（需要良好的設計）。
至于容器管理嗎，明天再談。
注1：如果業務開發人員具有很多的持久層框架經驗，當持久層框架更
換時，必然會造成他的極度不適應，這通常是系統移植成本很高的原因之一
注2 ：這是有可能的，類比一下C++和匯編語言，用Eclipse和用手工進行重構
注3：包括庫表修改、框架更換和方式的修改——事實上，如果業務邏輯發生了修改，那么持久層可能必須得改，但是如果持久層封裝的好的話，反之未必亦然
注4：公司重要的事情是盈利，根據技術辯證法，任何一個技術有有其優點也有其缺點，都有其適用和不適用的地方，新鮮的技術往往由于是對已有技術的革新，所
以在一段時間內會有很多潛在問題，作為愛好者去試用去跟技術的負責人聯系當然是沒問題，但是作為企業，對產品是質量要負有法律責任的，一般的公司當然都不
會愿意當新技術的小白鼠。相對而言，舊的技術由于擁有廣泛的使用，優點和缺點廣為人知，熟練開發人員也比較容易找到，可以在開發中規避其自身的缺點。當
然，不新鮮的也得看著要，得根據實際情況再作決定。