隨著Java的重新崛起，越來越多人開始使用Java，但是他們大多數(shù)人沒有做好足夠的思想準備，以致不能很好駕馭Java項目。中培偉業(yè)《JAVA高級開發(fā)技術(shù)實戰(zhàn)》培訓(xùn)專家龔老師認為，出現(xiàn)這一問題的根本原因在于很對開發(fā)人員存在認識上和方法上的誤區(qū)。

軟件的生命性

軟件是有生命的，這可能是老調(diào)重彈了，但是因為它事關(guān)分層架構(gòu)的原由，反復(fù)強調(diào)都不過分。

一個有生命的軟件首先必須有一個靈活可擴展的基礎(chǔ)架構(gòu)，其次才是完整的功能。

目前很多人對軟件的思想還是焦點落在后者：完整的功能，覺得一個軟件功能越完整越好，其實關(guān)鍵還是架構(gòu)的靈活性，就是前者，基礎(chǔ)架構(gòu)好，功能添加只是時間和工作量問題，但是如果架構(gòu)不好，功能再完整，也不可能包括未來所有功能，軟件是有生命的，在未來成長時，更多功能需要加入，但是因為基礎(chǔ)架構(gòu)不靈活不能方便加入，死路一條。

正因為普通人對軟件存在短視誤區(qū)，對功能追求高于基礎(chǔ)架構(gòu)，很多吃了虧的老程序員就此離開軟件行業(yè)，帶走寶貴的失敗經(jīng)驗，新的盲目的年輕程序員還是使用老的思維往前沖。

存儲過程和復(fù)雜SQL語句的陷阱

首先談?wù)劥鎯^程使用的誤區(qū)，使用存儲過程架構(gòu)的人以為可以解決性能問題，其實它正是導(dǎo)致性能問題的罪魁禍首之一

為什么這樣說呢?如果存儲過程都封裝了業(yè)務(wù)過程，那么運行負載都集中在數(shù)據(jù)庫端，要中間J2EE應(yīng)用服務(wù)器干什么?要中間服務(wù)器的分布式計算和集群能力做什么只能回到過去集中式數(shù)據(jù)庫主機時代。現(xiàn)在軟件都是面向互聯(lián)網(wǎng)的，不象過去那樣局限在一個小局域網(wǎng)，多用戶并發(fā)訪問量都是無法確定和衡量，依靠一臺數(shù)據(jù)庫主機顯然是不能夠承受這樣惡劣的用戶訪問環(huán)境的。

從分層角度來看，現(xiàn)在三層架構(gòu)：表現(xiàn)層、業(yè)務(wù)層和持久層，三個層次應(yīng)該分割明顯，職責(zé)分明：持久層職責(zé)持久化保存業(yè)務(wù)模型對象，業(yè)務(wù)層對持久層的調(diào)用只是幫助我們激活曾經(jīng)委托其保管的對象，所以，不能因為持久層是保管者，我們就以其為核心圍繞其編程，除了要求其歸還模型對象外，還要求其做其做復(fù)雜的業(yè)務(wù)組合。打個比喻：你在火車站將水果和盤子兩個對象委托保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子里，做成水果盤給你，合理嗎?

上面是談過分依賴持久層的一個現(xiàn)象，還有一個正好相反現(xiàn)象，持久層散發(fā)出來，開始擠占業(yè)務(wù)層，腐蝕業(yè)務(wù)層，整個業(yè)務(wù)層到處看見的是數(shù)據(jù)表的影子(包括數(shù)據(jù)表的字段，而不是業(yè)務(wù)對象。這樣程序員應(yīng)該多看看OO經(jīng)典PoEAAPoEAA 認為除了持久層，不應(yīng)該在其他地方看到數(shù)據(jù)表或表字段名。

當(dāng)然適量使用存儲過程，使用數(shù)據(jù)庫優(yōu)點也是允許的。按照Evans DDD理論，可以將SQL語句和存儲過程作為規(guī)則Specification一部分。

HibernateORM問題

現(xiàn)在使用Hibernate人也不少，但是他們發(fā)現(xiàn)Hibernate性能緩慢，所以尋求解決方案，其實并不是 Hibernate性能緩慢，而是我們使用方式發(fā)生錯誤：

“最近本人正搞一個項目，項目中我們用到了struts1.2+hibernate3, 由于關(guān)系復(fù)雜表和表之間的關(guān)系很多，在很多地方把lazy都設(shè)置false，所以導(dǎo)致數(shù)據(jù)一加載很慢，而且查詢一條數(shù)據(jù)更是非常的慢。

Hibernate是一個基于對象模型持久化的技術(shù)，因此，關(guān)鍵是我們需要設(shè)計出高質(zhì)量的對象模型，遵循DDD領(lǐng)域建模原則，減少降低關(guān)聯(lián)，通過分層等有效辦法處理關(guān)聯(lián)。如果采取圍繞數(shù)據(jù)表進行設(shè)計編程，加上表之間關(guān)系復(fù)雜沒有科學(xué)方法處理、偵察或減少這些關(guān)系，必然導(dǎo)致 系統(tǒng)運行緩慢，其實同樣問題也適用于當(dāng)初對EJB的實體BeanCMP抱怨上，實體BeanDomain Model持久化，如果不首先設(shè)計Domain Model，而是設(shè)計數(shù)據(jù)表，和持久化工具設(shè)計目標背道而馳，能不出問題嗎

Spring分層矛盾問題

Spring是以挑戰(zhàn)EJB面貌出現(xiàn)，其本身擁有的強大組件定制功能是優(yōu)點，但是存在實戰(zhàn)的一些問題，Spring作為業(yè)務(wù)層框架，不支持業(yè)務(wù)層Session 功能。

具體舉例如下：當(dāng)我們實現(xiàn)購物車之類業(yè)務(wù)功能時，需要將購物場合保存到Session中，由于業(yè)務(wù)層沒有方便的Session支持，我們只得將購物車保存到 HttpSession，而HttpSession只有通過HttpRequest才能獲得，再因為在Spring業(yè)務(wù)層容器中是無法訪問到HttpRequest這個對象的，所以， 最后我們只能將購物車保存到HttpSession”這個功能放在表現(xiàn)層中實現(xiàn)，而這個功能明顯應(yīng)該屬于業(yè)務(wù)層功能，這就導(dǎo)致我們的Java項目層次混亂，維護性差。 違背了使用Spring和分層架構(gòu)最初目的。

領(lǐng)域驅(qū)動設(shè)計DDD

龔老師指出，分層架構(gòu)是我們使用Java的根本原因之一，域建模專家Eric Evans在他的“Domain Model Design”一書中開篇首先強調(diào)的是分層架構(gòu)，整個DDD理論實際是告訴我們?nèi)绾问褂媚Ｐ蛯ο髈o技術(shù)和分層架構(gòu)來設(shè)計實現(xiàn)一個Java項目。

我們現(xiàn)在很多人知道Java項目基本有三層：表現(xiàn)層　業(yè)務(wù)層和持久層，當(dāng)我們執(zhí)著于討論各層框架如何選擇之時，實際上我們真正的項目開發(fā)工作還沒有開始， 就是我們選定了某種框架的組合Struts+Spring+HibernateStruts+EJBStruts+JdonFramework)，我們還沒有意識到業(yè)務(wù)層工作還需要大量工作，DDD提供了在業(yè)務(wù)層中再劃分新的層次思想，如領(lǐng)域?qū)雍头?wù)層，甚至再細分為作業(yè)層、能力層、策略層等等。通過層次細化方式達到復(fù)雜軟件的松耦合。DDD提供了如何細分層次的方式

當(dāng)我們將精力花費在架構(gòu)技術(shù)層面的討論和研究上時，我們可能忘記以何種依據(jù)選擇這些架構(gòu)技術(shù)?選擇標準是什么領(lǐng)域驅(qū)動設(shè)計DDD 回答了這樣的問題，DDD會告訴你如果一個框架不能協(xié)助你實現(xiàn)分層架構(gòu)，那就拋棄它，同時，DDD也指出選擇框架的考慮目的，使得你不會 人云亦云，陷入復(fù)雜的技術(shù)細節(jié)迷霧中，迷失了架構(gòu)選擇的根本方向。

現(xiàn)在也有些人誤以為DDD是一種新的理論，其實DDD和設(shè)計模式一樣，不是一種新的理論，而是實戰(zhàn)經(jīng)驗的總結(jié)，它將前人 使用面向模型設(shè)計的方法經(jīng)驗提煉出來，供后來者學(xué)習(xí)，以便迅速找到駕馭我們軟件項目的根本之道。

想了解更多IT資訊，請訪問中培偉業(yè)官網(wǎng)：中培偉業(yè)