其實標題起的太大，anyway, 實在是找不到合適的題目。
在OnV項目已經作了1年多了，有些感觸，寫下來以備以后整理之用。
好死不死負責Report這里，邏輯既復雜，Performance的要求又非常之高，與通常easy to code的J2EE其他模塊有很大的不同。
項目技術背景：
OR Mapping Tool:
Hibernate 2.0
Web tier:
Struts 1.2
Report Tool:
Jasper Reports
構架沒什么好說的，唯一特殊的是由于需求的關系，是multiple database (features and users兩個dimensions上的multiple)
幾點重要的經驗教訓：
1. Model Design一定要好，項目之初由于大家都比較缺乏經驗，尤其是一些Model由剛畢業的fresh people來做，實在后果不堪設想。
這里其實很推薦Martin的那本J2EE企業構架的書，也就是說OR Mapping的一些指導原則。
key point：lazy loading很重要；model之間的關聯盡可能是雙向，即便由于有些原因不能增加Hibernate語法上的association（Object A中有Object B作為屬性），那么最好也要有Objecd A中有一個ObjectBId，但相關聯將給query 帶來很大麻煩。 例如：如果需求有根據B的ID array去查詢A，那么沒有這種關系，則必須從Object B入手查詢A，這就造成unnecessary的2個表join 查詢，很耗費資源。
2. 盡可能地Batch操作，例如Batch save和loop save的操作，性能上天差地別。
3. 在類似Report的Query(意指查詢條件復雜，數據量大)，是不應當粗粒度操作的。一直覺得J2EE的一個特點就是，簡化developers的工作，面向對象，并且粗粒度。但是在這種性質的查詢里，如果粗粒度，結果就會導致性能的災難。其實這個是老調重彈，2002年左右我記得CSDN上就有人在詬病J2EE說性能如何的差。其實關鍵是developers是否估計到Use scenario對粒度的影響。簡化developers的工作是有限度的，OR mapping的工作也并不是為了使沒有經驗中學生就能夠很容易的寫出好的Enterprise application。其實數據更新也有類似的問題，例如無法update specific 的attribute而不得不更新整個Object，這個時候性能的差異就會體現出來，只不過大多數情況下，Object不會大到讓人無法接受，也不會像Report query那樣request大量的數據，所以這方面性能的影響，在一些系統中不會體現出來。
合理劃分Query的group，真實的目的是減少一次查詢中Join表的個數。Hibernate2的缺陷也可以有所規避（不能任意指定Join的方式）
如前所述，Report query很大程度上被Object Model Design所制約
還有別的一些雜感，例如Hibernate不能support View，動態mapping，都對提高Performance所能采取的stratagy做了限制。不過這些東西似乎在hibernate3中有了支持，還沒有時間用，不過已經讓team里的一個member去research一下hibernate3的new feature