越來越多人開始使用Java但是他們大多數人沒有做好足夠的思想准備（沒有接受OO思想體系相關培訓）以致不能很好駕馭Java項目甚至導致開發後的Java系統性能緩慢甚至經常當機很多人覺得這是Java復雜導致其實根本原因在於我們原先掌握的關於軟件知識（OO方面）不是太貧乏就是不恰當存在認識上和方法上的誤區
軟件的生命性
軟件是有生命的這可能是老調重彈了但是因為它事關分層架構的原由反復強調都不過分
一個有生命的軟件首先必須有一個靈活可擴展的基礎架構其次才是完整的功能
目前很多人對軟件的思想還是焦點落在後者完整的功能覺得一個軟件功能越完整越好其實關鍵還是架構的靈活性就是前者基礎架構好功能添加只是時間和工作量問題但是如果架構不好功能再完整也不可能包括未來所有功能軟件是有生命的在未來成長時更多功能需要加入但是因為基礎架構不靈活不能方便加入死路一條
正因為普通人對軟件存在短視誤區對功能追求高於基礎架構很多吃了虧的老程序員就此離開軟件行業帶走寶貴的失敗經驗新的盲目的年輕程序員還是使用老的思維往前沖其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱貌似非常符合胃口其實類似國內那些幾百元的盜版軟件擴展性以及持續發展性嚴重不足
那麼選擇現在一些流行的框架如HibernateSpring/Jdonframework是否就表示基礎架構打好了呢？其實還不盡然關鍵還是取決於你如何使用這些框架來搭建你的業務系統
存儲過程和復雜SQL語句的陷阱
首先談談存儲過程使用的誤區使用存儲過程架構的人以為可以解決性能問題其實它正是導致性能問題的罪魁禍首之一打個比喻如果一個人頻臨死亡打一針可以讓其延長半年但是打了這針其他所有醫療方案就全部失效請問你會使用這種短視方案嗎？
為什麼這樣說呢？如果存儲過程都封裝了業務過程那麼運行負載都集中在數據庫端要中間JEE應用服務器干什麼？要中間服務器的分布式計算和集群能力做什麼？只能回到過去集中式數據庫主機時代現在軟件都是面向互聯網的不象過去那樣局限在一個小局域網多用戶並發訪問量都是無法確定和衡量依靠一台數據庫主機顯然是不能夠承受這樣惡劣的用戶訪問環境的（當然搞數據庫集群也只是五十步和百步的區別）
從分層角度來看現在三層架構表現層業務層和持久層三個層次應該分割明顯職責分明持久層職責持久化保存業務模型對象業務層對持久層的調用只是幫助我們激活曾經委托其保管的對象所以不能因為持久層是保管者我們就以其為核心圍繞其編程除了要求其歸還模型對象外還要求其做其做復雜的業務組合打個比喻你在火車站將水果和盤子兩個對象委托保管處保管過了兩天來取時你還要求保管處將水果去皮切成塊放在盤子裡做成水果盤給你合理嗎？
上面是談過分依賴持久層的一個現象還有一個正好相反現象持久層散發出來開始擠占業務層腐蝕業務層整個業務層到處看見的是數據表的影子（包括數據表的字段）而不是業務對象這樣程序員應該多看看OO經典PoEAAPoEAA 認為除了持久層不應該在其他地方看到數據表或表字段名
當然適量使用存儲過程使用數據庫優點也是允許的按照Evans DDD理論可以將SQL語句和存儲過程作為規則Specification一部分
Hibernate等ORM問題
現在使用Hibernate人也不少
但是他們發現Hibernate性能緩慢
所以尋求解決方案
其實並不是 Hibernate性能緩慢
而是我們使用方式發生錯誤
最近本人正搞一個項目
項目中我們用到了struts
+hibernate
由於關系復雜表和表之間的關系很多
在很多地方把lazy都設置false
所以導致數據一加載很慢
而且查詢一條數據更是非常的慢
Hibernate是一個基於對象模型持久化的技術
因此
關鍵是我們需要設計出高質量的對象模型
遵循DDD領域建模原則
減少降低關聯
通過分層等有效辦法處理關聯
如果采取圍繞數據表進行設計編程
加上表之間關系復雜（沒有科學方法處理
偵察或減少這些關系）
必然導致 系統運行緩慢
其實同樣問題也適用於當初對EJB的實體Bean的CMP抱怨上
實體Bean是Domain Model持久化
如果不首先設計Domain Model
而是設計數據表
和持久化工具設計目標背道而馳
能不出問題嗎？關於這個問題N多年就在Jdon爭論過
這裡同樣延伸出另外一個問題
數據庫設計問題
數據庫是否需要在項目開始設計？
如果我們進行數據庫設計
那麼就產生了一系列問題
當我們使用Hibernate實現持久保存時
必須考慮事先設計好的數據庫表結構以及他們的關系如何和業務對象實現映射
這實際上是非常難實現的
這也是很多人覺得使用ORM框架棘手根本原因所在
當然
也有腦力相當發達的人可以實現
但是這種圍繞數據庫實現映射的結果必然扭曲業務對象
這類似於兩個板塊（數據表和業務對象）相撞
必然產生地震
地震的結果是兩敗俱傷
軟的一方吃虧
業務對象是代碼
相當於數據表結構
屬於軟的一方
最後導致業務對象變成數據傳輸對象DTO
DTO滿天飛
性能和維護問題隨之而來
領域建模解決了上述眾多不協調問題
特別是ORM痛苦使用問題
關於 ORM/Hibernate使用還是那句老話
如果你不掌握領域建模方法
那麼就不要用Hibernate
對於這個層次的你
也許No ORM 更是一個簡單之道
No ORM: The simplest solution
Spring分層矛盾問題
Spring是以挑戰EJB面貌出現
其本身擁有的強大組件定制功能是優點
但是存在實戰的一些問題
Spring作為業務層框架
不支持業務層Session 功能
具體舉例如下
當我們實現購物車之類業務功能時
需要將購物場合保存到 Session中
由於業務層沒有方便的Session支持
我們只得將購物車保存到 HttpSession
而HttpSession只有通過HttpRequest才能獲得
再因為在Spring業務層容器中是無法訪問到 HttpRequest這個對象的
所以
最後我們只能將
購物車保存到HttpSession
這個功能放在表現層中實現
而這個功能明顯應該屬於業務層功能
這就導致我們的Java項目層次混亂
維護性差
違背了使用Spring和分層架構最初目的
領域驅動設計DDD
現在回到我們討論的重點上來
分層架構是我們使用Java的根本原因之一
域建模專家Eric Evans在他的
Domain Model Design
一書中開篇首先強調的是分層架構
整個DDD理論實際是告訴我們如何使用模型對象oo技術和分層架構來設計實現一個Java項目
我們現在很多人知道Java項目基本有三層
表現層 業務層和持久層
當我們執著於討論各層框架如何選擇之時
實際上我們真正的項目開發工作還沒有開始
就是我們選定了某種框架的組合（如Struts+Spring+Hibernate或Struts+EJB或Struts+ JdonFramework）
我們還沒有意識到業務層工作還需要大量工作
DDD提供了在業務層中再劃分新的層次思想
如領域層和服務層
甚至再細分為作業層
能力層
策略層等等
通過層次細化方式達到復雜軟件的松耦合
DDD提供了如何細分層次的方式
當我們將精力花費在架構技術層面的討論和研究上時
我們可能忘記以何種依據選擇這些架構技術？選擇標准是什麼？領域驅動設計DDD 回答了這樣的問題
DDD會告訴你如果一個框架不能協助你實現分層架構
那就拋棄它
同時
DDD也指出選擇框架的考慮目的
使得你不會人雲亦雲
陷入復雜的技術細節迷霧中
迷失了架構選擇的根本方向
現在也有些人誤以為DDD是一種新的理論
其實DDD和設計模式一樣
不是一種新的理論
而是實戰經驗的總結
它將前人 使用面向模型設計的方法經驗提煉出來
供後來者學習
以便迅速找到駕馭我們軟件項目的根本之道
From:http://tw.wingwit.com/Article/program/Java/hx/201311/27128.html
