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