關鍵字：oo 回到我前面提出的觀點：“脫離了大量緩存和基于對象的業務邏輯的OO是沒有意義的”。其道理是顯而易見的，只有使用了大量緩存和基于對象的業務邏輯，建立一個OO結構的收益才遠大于我們付出的代價，OO本身所在的“內存對象世界”也才具備了脫離“持久化對象世界”而存在的根本意義。如果我們能把大量適合放在內存中的業務邏輯搬移到應用內存中（而不是DB Server）的話，那效果就更好。當然也有一些操作不適合放在應用邏輯中，如針對特別大量數據的非個性化的成批更新操作。至于什么叫大量，這取決于性能的考慮和實證。將很多業務邏輯從數據庫搬移到應用內存中是可行的，尤其是對于在執行前要根據很有限的數據條目進行大量判斷來決定是否實質性產生某種數據改變的邏輯更是如此。代價是速度可能較存儲過程差一點點，但是卻避免了因為大量不符合規則從而根本不會產生實質數據改變的無效調用而導致的應用服務器到數據服務器的網絡往復，二者相比，無謂的往復往往代價要高得多。對于現實的電子商務網站，這一點是非常有價值的。
2）OO并不是低性能的代名詞，設計合理的OO會帶來意想不到的高性能。
OO并不是低性能的代名詞。恰恰相反，很多時候我都把OO當作我提升網站性能的基本武器：通過結構合理而算法高效的對象緩存技術以及與對象結合并在同一地址空間中執行的業務邏輯，我們往往能夠輕易地提升系統的性能。當然，一切的前提在于正確的設計，這不斷適用于OO，也適用于世間一切，沒有什么東西脫離了其實現的細節而萬歲千古！
以我們最近完成的一個較大型電子商務網站為例（目前日均訂單〉12000，成交訂單筆數在3000左右，而且最近增長勢頭很好），在運行近三個月后，該網站在Alexa的速度統計已經從早先的very slow（平均一個頁面6~7妙），經過slow（Alexa的數據是累計的，所以不是立即跳變），上升到average（平均一個頁面2.0s）。與此同時，DB Server的CPU Usage從原來的平均80%急劇的下降到平均10%！在現有系統中，基本上除了一些大批量數據移動和數據庫服務器段數據分頁查詢之外，所有業務邏輯均存在于我們的應用邏輯中。這大概是違法很多朋友的開發直覺的。我經常聽到的是：用存儲過程吧，為了性能...我不是在一切場合都反對使用存儲過程。但是我們必須清楚，每一種方法的優點是什么？缺點是什么？條件是什么？什么場合適用？什么場合不會適用，什么場合二者應該在更細微的場景/場合下分別或者混合使用。這有點象物理中的定理：誰見過沒有適用條件的定理？
3）如果你關注Scale out的能力，你就更應該考慮OO。
現實世界的網站應用系統，都必須考慮Scalability問題，除非業務永不增長。只要業務會增長，使用人數不斷增多，服務器就一定會很快達到性能和并發極限。解決這個問題，通常只有兩個辦法：Scale up——買更好的服務器，而這往往因其代價過于高昂而不現實；Scale out——買更多的服務器，這往往是最終的實際選擇。但是Scale out始終面臨著數據集中（就算是拆分過的數據仍然各自相對集中，能做到無限隨意拆分嗎）的問題。如果大量的邏輯放在數據庫服務器一端，我相信很快數據庫服務器就會使得系統失去Scale out的能力和可能。因此，要保證Scale out的能力就必須保證數據庫（當然，必要的拆分策略也很重要，但那屬于另一個話題）只處理實質性的數據提交和不可避免的數據查詢，對于能夠避免的數據查詢和非實質性數據提交都應該想辦法予以避免。這其實和我們上面所說的“脫離了大量緩存和基于對象的業務邏輯的OO是沒有意義的”剛好結合起來，成為一舉奪得的美事。
4）OO + N-Tier的基本思想乃至軟件開發方法的所有其他動力是對邏輯聚合和復用地不斷追求。
大家都知道，軟件開發的分析設計方法一直在不端演化，新的概念不斷涌現。軟件開發也從最早的直線條的機器語言，到面向過程的匯編語言，再到面向對象的對象化分析設計及編程（繼承、接口、多態），以及后來的DP（設計模式）、AOP(面向方面的編程)...。一系列的演化，確實讓人有眼花繚亂之惑何從入手之惑。那么在這一演化過程中，一以貫之的是什么？始終不變的又是什么呢？
文章來源于領測軟件測試網 http://www.kjueaiud.com/