oo,來自實戰(zhàn)的深入思考

1、WhyOO多層結(jié)構(gòu)多層結(jié)構(gòu)來自實戰(zhàn)的深入思考來自實戰(zhàn)的深入思考面向?qū)ο蟮脑掝}本來是個老話題了。只是看到還有不少人對這個問題有所困惑，我也就不吝淺薄，談?wù)勛约簩γ嫦驅(qū)ο蟮睦斫?。還請大家在讀過之后，能夠不計鄙人的淺薄，多提寶貴意見。不斷地爭論和討論是前進的根本動力。面向?qū)ο蟮恼追椒ū緛砜梢苑譃槊嫦驅(qū)ο蠓治觥⒚嫦驅(qū)ο笤O(shè)計、面向?qū)ο缶幊痰取５窃谶@點上，我是贊同XP的開發(fā)思想的：代碼就是所有的設(shè)計。因此，我更愿意把面向?qū)ο罂醋饕粋€整體：一切最

2、終落實到體現(xiàn)了面向?qū)ο笏枷氲拇a。基于此種考慮，在這里我也不區(qū)分OOAOODOOP，而是泛指在面向?qū)ο笏枷胫笇碌能浖_發(fā)及實現(xiàn)全過程。需要注意的是：“體現(xiàn)了面向?qū)ο笏枷氲拇a”和“面向?qū)ο蟮拇a”是不同的概念C#java的語言特點決定了無論有沒有面向?qū)ο蟮撵`魂，其編碼的“肉體”都是面向?qū)ο蟮?。關(guān)于OO的應(yīng)用場合，還有很多人在爭論。前些天看到還有人說三層結(jié)構(gòu)多層結(jié)構(gòu)不適用于網(wǎng)站開發(fā)。從根本上講，這和OO是不是適用于網(wǎng)站開基本上是同一個問

3、題。因為，很顯然，OO和NTier常常是一件事情的兩個不同方面，使用OO卻不使用多層結(jié)構(gòu)是難以想象的，使用NTier卻不使用OO那我就更加不知其可了?？傊谖铱磥?，這兩件事情是緊密相連的。退一步講，將二者緊密聯(lián)系在一起，如果不是必然的話，至少也應(yīng)被看作是開發(fā)過程中的一個BestPractice。下面談?wù)勎覍ONTier的幾個基本觀點：1）脫離了大量緩存和基于對象的業(yè)務(wù)邏輯的OO是沒有意義的。我以前看到一些同道在進行OO開發(fā)的時候，對

4、象常常只在數(shù)據(jù)加載和保存中的出現(xiàn)。對象更像是一個盒子，在需要數(shù)據(jù)時，我們建立數(shù)據(jù)庫連接，獲取結(jié)果集或者DataReaderResultReader，將從數(shù)據(jù)庫獲得的數(shù)據(jù)“填充”到對象中，然后再將對象返回給上層應(yīng)用使用；在需要保存數(shù)據(jù)時，過程基本是對稱的：我們把對象中的數(shù)據(jù)，一個字段一個字段讀出來，生成參數(shù)化的或者直接字符串拼接的查詢語句，建立數(shù)據(jù)庫連接，提交更新到數(shù)據(jù)庫。如果OO的主要內(nèi)容就是這些的話，OO如果不能說是完全沒有意義的話，

5、起碼意義也不大。我們在付出了編寫了大量對象代碼并且在存儲加載時多一道手續(xù)的代碼和性能代價之后，得到的好處只是使上層應(yīng)用操作數(shù)據(jù)的代碼可讀性更好并且能夠進行一定的類型強制和檢查。這常常是很多開發(fā)人員對OO很困惑的原因：OO看起來很美，但是做了那么多事情，難道就是為了看起來很美嗎？這同時也成為一些編程老手把OO看作華而不實代名詞的原因：美是美了一點，但是代碼多了，性能差了，讓書呆子們?nèi)ビ冒伞Ｖ猿霈F(xiàn)這種局面，其根本原因在于“內(nèi)存對象世界”

6、沒有提供太多的附加值。大家應(yīng)該注意到“內(nèi)存對象世界”這一說法。在我看來，對象至少有兩個世界，一個是“持久化對象世界”，一個是“內(nèi)存對象世界”，這是由當今計算機的結(jié)構(gòu)特點決定的：如果數(shù)據(jù)要長期保存，數(shù)據(jù)就必須被保存到可持久化的媒介中；如果要進行運算，數(shù)據(jù)就必須被加載到可運算尋址的媒介中。前者就是DBServer等管理的硬盤、磁帶機...，后者就是內(nèi)存。在DBServer為中心的開發(fā)中，大家傾向于把所有邏輯直接放置在最接近“持久化對象世界”

7、的DBServer中，并主要以存儲過程的形式存在。但是這樣就一定是最合理的嗎？尤其是對于網(wǎng)站應(yīng)用？如果這樣確實是合理的話，OO還有什么意義呢？是不是OO真的如某些人所說，只適合于圖形繪制等特定領(lǐng)域？要回答這些問題，我們還是要看看哪些情況下，“內(nèi)存對象世界”能夠相對獨立于“持久化對象世界”發(fā)揮其作用，這樣“內(nèi)存對象世界”就具備了獨立于“持久化對象世界”之外的獨立意義。網(wǎng)站應(yīng)用的特點是：看數(shù)據(jù)的人多，創(chuàng)建數(shù)據(jù)的人少。眾所周知，恰恰就是這一點

8、決定了緩存對于網(wǎng)站系統(tǒng)的重要性。對于主要以靜態(tài)內(nèi)容為主的小型簡易網(wǎng)站，我們在這里就沒有討論的必要了。真正有人氣的網(wǎng)站一定是具有動態(tài)增長的準靜態(tài)內(nèi)容（如新聞類網(wǎng)站，內(nèi)容不斷增加，但是本身很少修改）或者大量動態(tài)內(nèi)容（如交易型的電子商務(wù)網(wǎng)站）的。對于前一種情況，通常有兩種方式來加速其訪問，一種是生成靜態(tài)頁面，一種是在內(nèi)存中緩存頁面內(nèi)容。生成靜態(tài)頁面在性能上未必總是最好的選擇。只有當數(shù)據(jù)多到內(nèi)存中根本緩存不下，而這些數(shù)據(jù)又都有很大可能被用戶訪問

9、時，生成靜態(tài)頁面才是較佳選擇。在數(shù)據(jù)較多，但是并發(fā)并不多時，或者并發(fā)雖多，但關(guān)注的內(nèi)容并不避免。這其實和我們上面所說的“脫離了大量緩存和基于對象的業(yè)務(wù)邏輯的OO是沒有意義的”剛好結(jié)合起來，成為一舉奪得的美事。4）OONTier的基本思想乃至軟件開發(fā)方法的所有其他動力是對邏輯聚合和復用地不斷追求。大家都知道，軟件開發(fā)的分析設(shè)計方法一直在不端演化，新的概念不斷涌現(xiàn)。軟件開發(fā)也從最早的直線條的機器語言，到面向過程的匯編語言，再到面向?qū)ο蟮膶ο?/p>

10、化分析設(shè)計及編程（繼承、接口、多態(tài)），以及后來的DP（設(shè)計模式）、AOP(面向方面的編程)...。一系列的演化，確實讓人有眼花繚亂之惑何從入手之惑。那么在這一演化過程中，一以貫之的是什么？始終不變的又是什么呢？在回答這個問題前，我們先來看一看MVC。MVC是現(xiàn)在大家都很熟悉的設(shè)計模式。那么到底什么是MVC呢？下面是Wikipedia關(guān)于MVC的解釋：ModelViewController(MVC)isasoftwarearchitect

11、urethatseparatesanapplicationsdatamodeluserinterfacecontrollogicintothreedistinctcomponentssothatmodificationstotheviewcomponentcanbemadewithminimalimpacttothedatamodelcomponent.翻譯過來就是：MVC是一種將應(yīng)用的數(shù)據(jù)模型、用戶界面（視圖）以及控制邏輯分解到不同組

12、件中的軟件構(gòu)架。這種分解可以使得視圖組件的細修改對數(shù)據(jù)模型只會產(chǎn)生很小的影響或者根本不產(chǎn)生影響，在思考問題的時候，我喜歡跳出問題來看問題，在跨越時間甚至跨越領(lǐng)域的大跨度類比中不斷完成思想的升級及重構(gòu)?；氐角懊娴膯栴}。在軟件開發(fā)分析設(shè)計方法上，一以貫之的其實就是一種類似于MVC的思想：對問題域不斷進行重構(gòu)，使得一種數(shù)據(jù)（不要狹隘的看待數(shù)據(jù)，信息、規(guī)則、動作，一切都可以被看作是數(shù)據(jù)）、該數(shù)據(jù)的管控邏輯、以及該數(shù)據(jù)的使用者（不一定是UI，UI

13、只是特例）能夠被區(qū)分開來。從這個角度來看待軟件開發(fā)領(lǐng)域的一切，你就會發(fā)現(xiàn)，一切都在改變，一切也都沒有改變。我們只是為我們一以貫之的方法找到了的應(yīng)用發(fā)領(lǐng)域。如此而已。再簡化一點，實質(zhì)上，一切軟件設(shè)計方法的突破都是在于指明新的邏輯聚合方向建立了新的邏輯聚合方法。OO如此，AOP如此，設(shè)計模式如此，一切都是如此。5）只有一些很特定的情況不適用OONTier。當然不是所有場合都必須或者適用OONpTier，因為二者的引入無疑會在某些方面增加成本

14、，因此我們必須考慮我們付出的時候會得到什么，我們得到的時候又會失去什么？權(quán)衡——這實際上也是我們做一切事情的最基本思路，而不只是針對軟件開發(fā)。大家可以自己權(quán)衡何時使用OONTier。下面是我認為不適合的一些場合：a)太簡單的應(yīng)用，寫起來沒幾句代碼，使用OONTier根本不值得b)已經(jīng)有一套很接近目標系統(tǒng)的原型系統(tǒng)，暫時沒有必要使用OONTier，因為成本不合算c)開發(fā)人員完全不知道該怎么使用OONTier，教育成本不低，暫時不建議使用d