Java已經(jīng)被越來越多的人熟悉和使用，但是開發(fā)后的Java系統(tǒng)性能緩慢甚至當(dāng)機的現(xiàn)象也經(jīng)常發(fā)生。很多人并不能很好地駕馭Java項目。他們覺得Java技術(shù)很復(fù)雜，其實不然。根本原因在于：我們原先掌握的關(guān)于軟件知識(OO方面)太欠缺了，存在很多認(rèn)識上的誤區(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)驗，新的盲目的年輕程序員還是使用老的思維往前沖。其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內(nèi)那些幾百元的盜版軟件，擴展性以及持續(xù)發(fā)展性嚴(yán)重不足。
那么選擇現(xiàn)在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎(chǔ)架構(gòu)打好了呢？其實還不盡然，關(guān)鍵還是取決于你如何使用這些框架來搭建你的業(yè)務(wù)系統(tǒng)。
Hibernate等ORM問題
現(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ù)表進(jìn)行設(shè)計編程，加上表之間關(guān)系復(fù)雜（沒有科學(xué)方法處理、偵察或減少這些關(guān)系），必然導(dǎo)致 系統(tǒng)運行緩慢，其實同樣問題也適用于當(dāng)初對EJB的實體Bean的CMP抱怨上，實體Bean是Domain Model持久化，如果不首先設(shè)計Domain Model，而是設(shè)計數(shù)據(jù)表，和持久化工具設(shè)計目標(biāo)背道而馳，能不出問題嗎？關(guān)于這個問題N多年就在Jdon爭論過。
這里同樣延伸出另外一個問題：數(shù)據(jù)庫設(shè)計問題，數(shù)據(jù)庫是否需要在項目開始設(shè)計？
如果我們進(jìn)行數(shù)據(jù)庫設(shè)計，那么就產(chǎn)生了一系列問題：當(dāng)我們使用Hibernate實現(xiàn)持久保存時，必須考慮事先設(shè)計好的數(shù)據(jù)庫表結(jié)構(gòu)以及他們的關(guān)系如何和業(yè)務(wù)對象實現(xiàn)映射，這實際上是非常難實現(xiàn)的，這也是很多人覺得使用ORM框架棘手根本原因所在。
當(dāng)然，也有腦力相當(dāng)發(fā)達(dá)的人可以 實現(xiàn)，但是這種圍繞數(shù)據(jù)庫實現(xiàn)映射的結(jié)果必然扭曲業(yè)務(wù)對象，這類似于兩個板塊（數(shù)據(jù)表和業(yè)務(wù)對象）相撞，必然產(chǎn)生地震，地震的結(jié)果是兩敗俱傷， 軟的一方吃虧，業(yè)務(wù)對象是代碼，相當(dāng)于數(shù)據(jù)表結(jié)構(gòu)，屬于軟的一方，最后導(dǎo)致業(yè)務(wù)對象變成數(shù)據(jù)傳輸對象DTO, DTO滿天飛，性能和維護(hù)問題隨之而來。
領(lǐng)域建模解決了上述眾多不協(xié)調(diào)問題，特別是ORM痛苦使用問題，關(guān)于ORM/Hibernate使用還是那句老話：如果你不掌握領(lǐng)域建模方法，那么就不要用Hibernate，對于這個層次的你：也許No ORM 更是一個簡單之道
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項目層次混亂，維護(hù)性差。 違背了使用Spring和分層架構(gòu)最初目的。
存儲過程和復(fù)雜SQL語句的陷阱
延伸閱讀
學(xué)習(xí)是年輕人改變自己的最好方式