越來(lái)越多人開(kāi)始使用Java，但是他們大多數(shù)人沒(méi)有做好足夠的思想準(zhǔn)備(沒(méi)有接受OO思想體系相關(guān)培訓(xùn))，以致不能很好駕馭Java項(xiàng)目，甚至 導(dǎo)致開(kāi)發(fā)后的Java系統(tǒng)性能緩慢甚至經(jīng)常當(dāng)機(jī)。很多人覺(jué)得這是Java復(fù)雜導(dǎo)致，其實(shí)根本原因在于：我們?cè)日莆盏年P(guān)于軟件知識(shí)(OO方面)不是太貧乏就是不恰當(dāng)，存在認(rèn)識(shí)上和方法上的誤區(qū)。
軟件的生命性
軟件是有生命的，這可能是老調(diào)重彈了，但是因?yàn)樗玛P(guān)分層架構(gòu)的原由，反復(fù)強(qiáng)調(diào)都不過(guò)分。
一個(gè)有生命的軟件首先必須有一個(gè)靈活可擴(kuò)展的基礎(chǔ)架構(gòu)，其次才是完整的功能。
目前很多人對(duì)軟件的思想還是焦點(diǎn)落在后者：完整的功能，覺(jué)得一個(gè)軟件功能越完整越好，其實(shí)關(guān)鍵還是架構(gòu)的靈活性，就是前者，基礎(chǔ)架構(gòu)好，功能添加只是時(shí)間和工作量問(wèn)題，但是如果架構(gòu)不好，功能再完整，也不可能包括未來(lái)所有功能，軟件是有生命的，在未來(lái)成長(zhǎng)時(shí)，更多功能需要加入，但是因?yàn)榛A(chǔ)架構(gòu)不靈活不能方便加入，死路一條。
正因?yàn)槠胀ㄈ藢?duì)軟件存在短視誤區(qū)，對(duì)功能追求高于基礎(chǔ)架構(gòu)，很多吃了虧的老程序員就此離開(kāi)軟件行業(yè)，帶走寶貴的失敗經(jīng)驗(yàn)，新的盲目的年輕程序員還是使用老的思維往前沖。其實(shí)很多國(guó)外免費(fèi)開(kāi)源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實(shí)類(lèi)似國(guó)內(nèi)那些幾百元的盜版軟件，擴(kuò)展性以及持續(xù)發(fā)展性嚴(yán)重不足。
那么選擇現(xiàn)在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎(chǔ)架構(gòu)打好了呢？其實(shí)還不盡然，關(guān)鍵還是取決于你如何使用這些框架來(lái)搭建你的業(yè)務(wù)系統(tǒng)。
存儲(chǔ)過(guò)程和復(fù)雜SQL語(yǔ)句的陷阱
首先談?wù)劥鎯?chǔ)過(guò)程使用的誤區(qū)，使用存儲(chǔ)過(guò)程架構(gòu)的人以為可以解決性能問(wèn)題，其實(shí)它正是導(dǎo)致性能問(wèn)題的罪魁禍?zhǔn)字�，打個(gè)比喻：如果一個(gè)人頻臨死亡，打一針可以讓其延長(zhǎng)半年，但是打了這針，其他所有醫(yī)療方案就全部失效，請(qǐng)問(wèn)你會(huì)使用這種短視方案嗎？
為什么這樣說(shuō)呢？如果存儲(chǔ)過(guò)程都封裝了業(yè)務(wù)過(guò)程，那么運(yùn)行負(fù)載都集中在數(shù)據(jù)庫(kù)端，要中間J2EE應(yīng)用服務(wù)器干什么？要中間服務(wù)器的分布式計(jì)算和集群能力做什么？只能回到過(guò)去集中式數(shù)據(jù)庫(kù)主機(jī)時(shí)代�，F(xiàn)在軟件都是面向互聯(lián)網(wǎng)的，不象過(guò)去那樣局限在一個(gè)小局域網(wǎng)，多用戶(hù)并發(fā)訪問(wèn)量都是無(wú)法確定和衡量，依靠一臺(tái)數(shù)據(jù)庫(kù)主機(jī)顯然是不能夠承受這樣惡劣的用戶(hù)訪問(wèn)環(huán)境的。（當(dāng)然搞數(shù)據(jù)庫(kù)集群也只是五十步和百步的區(qū)別）。
從分層角度來(lái)看，現(xiàn)在三層架構(gòu)：表現(xiàn)層、業(yè)務(wù)層和持久層，三個(gè)層次應(yīng)該分割明顯，職責(zé)分明：持久層職責(zé)持久化保存業(yè)務(wù)模型對(duì)象，業(yè)務(wù)層對(duì)持久層的調(diào)用只是幫助我們激活曾經(jīng)委托其保管的對(duì)象，所以，不能因?yàn)槌志脤邮潜９苷�，我們就以其為核心圍繞其編程，除了要求其歸還模型對(duì)象外，還要求其做其做復(fù)雜的業(yè)務(wù)組合。打個(gè)比喻：你在火車(chē)站將水果和盤(pán)子兩個(gè)對(duì)象委托保管處保管，過(guò)了兩天來(lái)取時(shí)，你還要求保管處將水果去皮切成塊，放在盤(pán)子里，做成水果盤(pán)給你，合理嗎？
上面是談過(guò)分依賴(lài)持久層的一個(gè)現(xiàn)象，還有一個(gè)正好相反現(xiàn)象，持久層散發(fā)出來(lái)，開(kāi)始擠占業(yè)務(wù)層，腐蝕業(yè)務(wù)層，整個(gè)業(yè)務(wù)層到處看見(jiàn)的是數(shù)據(jù)表的影子（包括數(shù)據(jù)表的字段），而不是業(yè)務(wù)對(duì)象。這樣程序員應(yīng)該多看看OO經(jīng)典PoEAA。PoEAA 認(rèn)為除了持久層，不應(yīng)該在其他地方看到數(shù)據(jù)表或表字段名。
當(dāng)然適量使用存儲(chǔ)過(guò)程，使用數(shù)據(jù)庫(kù)優(yōu)點(diǎn)也是允許的。按照Evans DDD理論，可以將SQL語(yǔ)句和存儲(chǔ)過(guò)程作為規(guī)則Specification一部分。
Hibernate等ORM問(wèn)題
現(xiàn)在使用Hibernate人也不少，但是他們發(fā)現(xiàn)Hibernate性能緩慢，所以尋求解決方案，其實(shí)并不是 Hibernate性能緩慢，而是我們使用方式發(fā)生錯(cuò)誤：
“最近本人正搞一個(gè)項(xiàng)目，項(xiàng)目中我們用到了struts1.2+hibernate3, 由于關(guān)系復(fù)雜表和表之間的關(guān)系很多，在很多地方把lazy都設(shè)置false，所以導(dǎo)致數(shù)據(jù)一加載很慢，而且查詢(xún)一條數(shù)據(jù)更是非常的慢�！�
Hibernate是一個(gè)基于對(duì)象模型持久化的技術(shù)，因此，關(guān)鍵是我們需要設(shè)計(jì)出高質(zhì)量的對(duì)象模型，遵循DDD領(lǐng)域建模原則，減少降低關(guān)聯(lián)，通過(guò)分層等有效辦法處理關(guān)聯(lián)。如果采取圍繞數(shù)據(jù)表進(jìn)行設(shè)計(jì)編程，加上表之間關(guān)系復(fù)雜（沒(méi)有科學(xué)方法處理、偵察或減少這些關(guān)系），必然導(dǎo)致 系統(tǒng)運(yùn)行緩慢，其實(shí)同樣問(wèn)題也適用于當(dāng)初對(duì)EJB的實(shí)體Bean的CMP抱怨上，實(shí)體Bean是Domain Model持久化，如果不首先設(shè)計(jì)Domain Model，而是設(shè)計(jì)數(shù)據(jù)表，和持久化工具設(shè)計(jì)目標(biāo)背道而馳，能不出問(wèn)題嗎？關(guān)于這個(gè)問(wèn)題N多年就在Jdon爭(zhēng)論過(guò)。
這里同樣延伸出另外一個(gè)問(wèn)題：數(shù)據(jù)庫(kù)設(shè)計(jì)問(wèn)題，數(shù)據(jù)庫(kù)是否需要在項(xiàng)目開(kāi)始設(shè)計(jì)？
如果我們進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)，那么就產(chǎn)生了一系列問(wèn)題：當(dāng)我們使用Hibernate實(shí)現(xiàn)持久保存時(shí)，必須考慮事先設(shè)計(jì)好的數(shù)據(jù)庫(kù)表結(jié)構(gòu)以及他們的關(guān)系如何和業(yè)務(wù)對(duì)象實(shí)現(xiàn)映射，這實(shí)際上是非常難實(shí)現(xiàn)的，這也是很多人覺(jué)得使用ORM框架棘手根本原因所在。
當(dāng)然，也有腦力相當(dāng)發(fā)達(dá)的人可以 實(shí)現(xiàn)，但是這種圍繞數(shù)據(jù)庫(kù)實(shí)現(xiàn)映射的結(jié)果必然扭曲業(yè)務(wù)對(duì)象，這類(lèi)似于兩個(gè)板塊（數(shù)據(jù)表和業(yè)務(wù)對(duì)象）相撞，必然產(chǎn)生地震，地震的結(jié)果是兩敗俱傷， 軟的一方吃虧，業(yè)務(wù)對(duì)象是代碼，相當(dāng)于數(shù)據(jù)表結(jié)構(gòu)，屬于軟的一方，最后導(dǎo)致業(yè)務(wù)對(duì)象變成數(shù)據(jù)傳輸對(duì)象DTO, DTO滿(mǎn)天飛，性能和維護(hù)問(wèn)題隨之而來(lái)。
領(lǐng)域建模解決了上述眾多不協(xié)調(diào)問(wèn)題，特別是ORM痛苦使用問(wèn)題，關(guān)于ORM/Hibernate使用還是那句老話(huà)：如果你不掌握領(lǐng)域建模方法，那么就不要用Hibernate，對(duì)于這個(gè)層次的你：也許No ORM 更是一個(gè)簡(jiǎn)單之道： No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715
Spring分層矛盾問(wèn)題
Spring是以挑戰(zhàn)EJB面貌出現(xiàn)，其本身?yè)碛械膹?qiáng)大組件定制功能是優(yōu)點(diǎn)，但是存在實(shí)戰(zhàn)的一些問(wèn)題，Spring作為業(yè)務(wù)層框架，不支持業(yè)務(wù)層Session 功能。
具體舉例如下：當(dāng)我們實(shí)現(xiàn)購(gòu)物車(chē)之類(lèi)業(yè)務(wù)功能時(shí)，需要將購(gòu)物場(chǎng)合保存到Session中，由于業(yè)務(wù)層沒(méi)有方便的Session支持，我們只得將購(gòu)物車(chē)保存到 HttpSession，而HttpSession只有通過(guò)HttpRequest才能獲得，再因?yàn)樵赟pring業(yè)務(wù)層容器中是無(wú)法訪問(wèn)到HttpRequest這個(gè)對(duì)象的，所以， 最后我們只能將“購(gòu)物車(chē)保存到HttpSession”這個(gè)功能放在表現(xiàn)層中實(shí)現(xiàn)，而這個(gè)功能明顯應(yīng)該屬于業(yè)務(wù)層功能，這就導(dǎo)致我們的Java項(xiàng)目層次混亂，維護(hù)性差。 違背了使用Spring和分層架構(gòu)最初目的。
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD
現(xiàn)在回到我們討論的重點(diǎn)上來(lái)，分層架構(gòu)是我們使用Java的根本原因之一，域建模專(zhuān)家Eric Evans在他的“Domain Model Design”一書(shū)中開(kāi)篇首先強(qiáng)調(diào)的是分層架構(gòu)，整個(gè)DDD理論實(shí)際是告訴我們?nèi)绾问褂媚Ｐ蛯?duì)象oo技術(shù)和分層架構(gòu)來(lái)設(shè)計(jì)實(shí)現(xiàn)一個(gè)Java項(xiàng)目。
我們現(xiàn)在很多人知道Java項(xiàng)目基本有三層：表現(xiàn)層 業(yè)務(wù)層和持久層，當(dāng)我們執(zhí)著于討論各層框架如何選擇之時(shí)，實(shí)際上我們真正的項(xiàng)目開(kāi)發(fā)工作還沒(méi)有開(kāi)始， 就是我們選定了某種框架的組合（如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework），我們還沒(méi)有意識(shí)到業(yè)務(wù)層工作還需要大量工作，DDD提供了在業(yè)務(wù)層中再劃分新的層次思想，如領(lǐng)域?qū)雍头⻊?wù)層，甚至再細(xì)分為作業(yè)層、能力層、策略層等等。通過(guò)層次細(xì)化方式達(dá)到復(fù)雜軟件的松耦合。DDD提供了如何細(xì)分層次的方式
當(dāng)我們將精力花費(fèi)在架構(gòu)技術(shù)層面的討論和研究上時(shí)，我們可能忘記以何種依據(jù)選擇這些架構(gòu)技術(shù)？選擇標(biāo)準(zhǔn)是什么？領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD 回答了這樣的問(wèn)題，DDD會(huì)告訴你如果一個(gè)框架不能協(xié)助你實(shí)現(xiàn)分層架構(gòu)，那就拋棄它，同時(shí)，DDD也指出選擇框架的考慮目的，使得你不會(huì) 人云亦云，陷入復(fù)雜的技術(shù)細(xì)節(jié)迷霧中，迷失了架構(gòu)選擇的根本方向。
現(xiàn)在也有些人誤以為DDD是一種新的理論，其實(shí)DDD和設(shè)計(jì)模式一樣，不是一種新的理論，而是實(shí)戰(zhàn)經(jīng)驗(yàn)的總結(jié)，它將前人 使用面向模型設(shè)計(jì)的方法經(jīng)驗(yàn)提煉出來(lái)，供后來(lái)者學(xué)習(xí)，以便迅速找到駕馭我們軟件項(xiàng)目的根本之道。
|
