越來越多人開始使用Java，但是他們大多數人沒有做好足夠的思想準備(沒有接受OO思想體系相關培訓)，以致不能很好駕馭Java項目，甚至 導致開發後的Java系統性能緩慢甚至經常當機。很多人覺得這是Java複雜導致，其實根本原因在於：我們原先掌握的關於軟件知識(OO方面)不是太貧乏就是不恰當，存在認識上和方法上的誤區。
軟件的生命性
軟件是有生命的，這可能是老調重彈了，但是因爲它事關分層架構的原由，反覆強調都不過分。
一個有生命的軟件首先必須有一個靈活可擴展的基礎架構，其次纔是完整的功能。
目前很多人對軟件的思想還是焦點落在後者：完整的功能，覺得一個軟件功能越完整越好，其實關鍵還是架構的靈活性，就是前者，基礎架構好，功能添加只是時間和工作量問題，但是如果架構不好，功能再完整，也不可能包括未來所有功能，軟件是有生命的，在未來成長時，更多功能需要加入，但是因爲基礎架構不靈活不能方便加入，死路一條。 正因爲普通人對軟件存在短視誤區，對功能追求高於基礎架構，很多吃了虧的老程序員就此離開軟件行業，帶走寶貴的失敗經驗，新的盲目的年輕程序員還是使用老的思維往前衝。其實很多國外免費開源框架如ofbizcompiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內那些幾百元的盜版軟件，擴展性以及持續發展性嚴重不足。
那麼選擇現在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢？其實還不盡然，關鍵還是取決於你如何使用這些框架來搭建你的業務系統。
存儲過程和複雜SQL語句的陷阱
首先談談存儲過程使用的誤區，使用存儲過程架構的人以爲可以解決性能問題，其實它正是導致性能問題的罪魁禍首之一，打個比喻：如果一個人頻臨死亡，打一針可以讓其延長半年，但是打了這針，其他所有醫療方案就全部失效，請問你會使用這種短視方案嗎？
爲什麼這樣說呢？如果存儲過程都封裝了業務過程，那麼運行負載都集中在數據庫端，要中間J2EE應用服務器幹什麼？要中間服務器的分佈式計算和集羣能力做什麼？只能回到過去集中式數據庫主機時代。現在軟件都是面向互聯網的，不象過去那樣侷限在一個小局域網，多用戶併發訪問量都是無法確定和衡量，依靠一臺數據庫主機顯然是不能夠承受這樣惡劣的用戶訪問環境的。（當然搞數據庫集羣也只是五十步和百步的區別）。
從分層角度來看，現在三層架構：表現層、業務層和持久層，三個層次應該分割明顯，職責分明：持久層職責持久化保存業務模型對象，業務層對持久層的調用只是幫助我們激活曾經委託其保管的對象，所以，不能因爲持久層是保管者，我們就以其爲核心圍繞其編程，除了要求其歸還模型對象外，還要求其做其做複雜的業務組合。打個比喻：你在火車站將水果和盤子兩個對象委託保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子裏，做成水果盤給你，合理嗎？
上面是談過分依賴持久層的一個現象，還有一個正好相反現象，持久層散發出來，開始擠佔業務層，腐蝕業務層，整個業務層到處看見的是數據表的影子（包括數據表的字段），而不是業務對象。這樣程序員應該多看看OO經典PoEAA。PoEAA 認爲除了持久層，不應該在其他地方看到數據表或表字段名。
當然適量使用存儲過程，使用數據庫優點也是允許的。按照Evans DDD理論，可以將SQL語句和存儲過程作爲規則Specification一部分。
Hibernate等ORM問題
現在使用Hibernate人也不少，但是他們發現Hibernate性能緩慢，所以尋求解決方案，其實並不是 Hibernate性能緩慢，而是我們使用方式發生錯誤：
“最近本人正搞一個項目，項目中我們用到了struts1.2+hibernate3, 由於關係複雜表和表之間的關係很多，在很多地方把lazy都設置false，所以導致數據一加載很慢，而且查詢一條數據更是非常的慢。”
Hibernate是一個基於對象模型持久化的技術，因此，關鍵是我們需要設計出高質量的對象模型，遵循DDD領域建模原則，減少降低關聯，通過分層等有效辦法處理關聯。如果採取圍繞數據表進行設計編程，加上表之間關係複雜（沒有科學方法處理、偵察或減少這些關係），必然導致系統運行緩慢，其實同樣問題也適用於當初對EJB的實體Bean的CMP抱怨上，實體Bean是DomainModel持久化，如果不首先設計DomainModel，而是設計數據表，和持久化工具設計目標背道而馳，能不出問題嗎？關於這個問題N多年就在Jdon爭論過。
這裏同樣延伸出另外一個問題：數據庫設計問題，數據庫是否需要在項目開始設計？如果我們進行數據庫設計，那麼就產生了一系列問題：當我們使用Hibernate實現持久保存時，必須考慮事先設計好的數據庫表結構以及他們的關係如何和業務對象實現映射，這實際上是非常難實現的，這也是很多人覺得使用ORM框架棘手根本原因所在。
當然，也有腦力相當發達的人可以實現，但是這種圍繞數據庫實現映射的結果必然扭曲業務對象，這類似於兩個板塊（數據表和業務對象）相撞，必然產生地震，地震的結果是兩敗俱傷，軟的一方吃虧，業務對象是代碼，相當於數據表結構，屬於軟的一方，最後導致業務對象變成數據傳輸對象DTO, DTO滿天飛，性能和維護問題隨之而來。
領域建模解決了上述衆多不協調問題，特別是ORM痛苦使用問題，關於ORM/Hibernate使用還是那句老話：如果你不掌握領域建模方法，那麼就不要用Hibernate，對於這個層次的你：也許No ORM 更是一個簡單之道： No ORM: The simplestsolution
-------------------------------------------------------------------------------------------------
移動開發者大會：Android開發者將越來越賺錢 海量Android教程、開發資料和源碼
10類最急需IT人才：Java開發者居首 給將成爲“Android高手”的10個建議
成爲Java高手的25個學習目標--非常經典 Android 4.1果凍豆新特性詳解
芯片巨頭海思和展訊：給中國芯片業帶來信心 海量經典Java教程、學習資料和源碼
Java侵權訴訟Google獲勝,Android厚積薄發 面試必備：Android筆試總結
Android高手必須掌握的28大內容和10個建議 Android平臺研發人才缺口30萬
Android開發環境安裝和配置步驟詳細圖解 2012國內移動App開發者大調查結果
Windows 7下搭建android開發環境步驟圖解 Android 4.0的30個突出的新特性
Android高手要經過的6個階段和6個境界 linux下搭建Android開發環境步驟
從IT菜鳥變爲“IT骨幹開發者”的11個建議 程序員編程技術迅速提高的終極攻略
2012世界各國人均GDP排名,中國超泰國 2012年全國各省平均工資排行
2012年中國大學高校排行榜（580強排名） 中國各省市面積和人口數量排名
中國百萬開發者大調查：程序員的薪水不錯 Java高手需要越過的10座高山
周立功談嵌入式：我的25年嵌入式生涯 Android和Java語言的異同和關係
華爲中國區手機銷量達千萬,80%爲智能機 谷歌Android碎片化嚴重
2012年中國各省GDP和人均GDP排名 90後就業“錢景”:IT仍是最佳選擇
2012全球城市競爭力500強，69箇中國城市上榜 不要做浮躁的軟件工程師
2012年世界500強，79家大陸香港臺灣公司上榜名單 給IT新兵的15個建議
美國知名科技公司入門級軟件工程師的薪水排名 回顧Java經過的風風雨雨
71道經典Android面試題和答案--重要知識點都涉及到了
