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