當前Java軟體開發中幾種認識誤區

越來越多人開始使用Java，但是他們大多數人沒有做好足夠的思想準備(沒有接受OO思想體系相關培訓)，以致不能很好駕馭Java項目，甚至導致開發後的Java系統效能緩慢甚至經常當機。很多人覺得這是Java複雜導致，其實根本原因在於:我們原先掌握的關於軟體知識(OO方面)不是太貧乏就是不恰當，存在認識上和方法上的誤區。

軟體的生命性

軟體是有生命的，這可能是老調重彈了，但是因為它事關分層架構的原由，反覆強調都不過分。

一個有生命的軟體首先必須有一個靈活可擴充的基礎架構，其次才是完整的功能。

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

正因為普通人對軟體存在短視誤區，對功能追求高於基礎架構，很多吃了虧的老程式員就此離開軟體行業，帶走寶貴的失敗經驗，新的盲目的年輕程式員還是使用老的思維往前沖。其實很多國外免費開源架構如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內那些幾百元的盜版軟體，擴充性以及持續發展性嚴重不足。

那麼選擇現在一些流行的架構如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢?其實還不盡然，關鍵還是取決於你如何使用這些架構來搭建你的業務系統。

預存程序和複雜SQL語句的陷阱

首先談談預存程序使用的誤區，使用預存程序架構的人以為可以解決效能問題，其實它正是導致效能問題的罪魁禍首之一，打個比喻:如果一個人頻臨死亡，打一針可以讓其延長半年，但是打了這針，其他所有醫學方案就全部失效，請問你會使用這種短視方案嗎?

為什麼這樣說呢?如果預存程序都封裝了業務過程，那麼運行負載都集中在資料庫端，要中間J2EE應用伺服器幹什麼?要中間伺服器的分散式運算和叢集能力做什麼?只能回到過去集中式資料庫主機時代。現在軟體都是面向互連網的，不象過去那樣局限在一個小區域網路，多使用者並發訪問量都是無法確定和衡量，依靠一台資料庫主機顯然是不能夠承受這樣惡劣的使用者訪問環境的。(當然搞資料庫叢集也只是五十步和百步的區別)。

從分層角度來看，現在三層架構:表現層、業務層和持久層，三個層次應該分割明顯，職責分明:持久層職責持久化儲存業務模型對象，業務層對持久層的調用只是協助我們啟用曾經委託其保管的對象，所以，不能因為持久層是保管者，我們就以其為核心圍繞其編程，除了要求其歸還模型對象外，還要求其做其做複雜的業務組合。打個比喻:你在火車站將水果和盤子兩個對象委託保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子裡，做成水果盤給你，合理嗎?

上面是談過分依賴持久層的一個現象，還有一個正好相反現象，持久層散發出來，開始擠占業務層，腐蝕業務層，整個業務層到處看見的是資料表的影子(包括資料表的欄位)，而不是業務對象。這樣程式員應該多看看OO經典PoEAA。PoEAA 認為除了持久層，不應該在其他地方看到資料表或表欄位名。

當然適量使用預存程序，使用資料庫優點也是允許的。按照Evans DDD理論，可以將SQL語句和預存程序作為規則Specification一部分。