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