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

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

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

　　正因為普通人對軟件存在短視誤區，對功能追求高于基礎架構，很多吃了虧的老程序員就此離開軟件行業，帶走寶貴的失敗經驗，新的盲目的年輕程序員還是使用老的思維往前沖。其實很多國外免費開源框架如ofbiz compiere和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是Domain Model持久化，如果不首先設計Domain Model，而是設計數據表，和持久化工具設計目標背道而馳，能不出問題嗎?關于這個問題N多年就在Jdon爭論過。