noun:
1. The act or an instance of emitting.
2. Something emitted.
3. A substance discharged into the air, especially by an internal combustion engine.
]]>
在OnV目已经作了1q多了，有些感触Q写下来以备以后整理之用?BR>好死不死负责Reportq里Q逻辑既复杂，Performance的要求又非常之高Q与通常easy to code的J2EE其他模块有很大的不同?BR>
目技术背景：
OR Mapping Tool:
Hibernate 2.0
Web tier:
Struts 1.2
Report Tool:
Jasper Reports
构架没什么好说的Q唯一Ҏ的是׃需求的关系Q是multiple database (features and users两个dimensions上的multiple)
几点重要的经验教训：
1. Model Design一定要好，目之初׃大家都比较缺乏经验，其是一些Model由刚毕业的fresh people来做Q实在后果不堪设惟?BR>q里其实很推荐Martin的那本J2EE企业构架的书Q也是说OR Mapping的一些指导原则?BR>key pointQlazy loading很重要；model之间的关联尽可能是双向，即便׃有些原因不能增加Hibernate语法上的associationQObject A中有Object B作ؓ属性）Q那么最好也要有Objecd A中有一个ObjectBIdQ但相关联将lquery 带来很大ȝ?例如Q如果需求有ҎB的ID arrayL询AQ那么没有这U关p，则必MObject B入手查询AQ这造成unnecessary?个表join 查询Q很耗费资源?BR>2. 可能地Batch操作Q例如Batch save和loop save的操作，性能上天差地别?BR>3. 在类似Report的Query(意指查询条g复杂Q数据量?Q?STRONG>是不应当_粒度操作的。一直觉得J2EE的一个特点就是，化developers的工作，面向对象Qƈ且粗_度。但是在q种性质的查询里Q如果粗_度Q结果就会导致性能的灾难。其实这个是老调重弹Q?002q左x记得CSDN上就有h在诟病J2EE说性能如何的差。其实关键是developers是否估计到Use scenario对粒度的影响。简化developers的工作是有限度的QOR mapping的工作也q不是ؓ了没有l验中学生就能够很容易的写出好的Enterprise application。其实数据更C有类似的问题Q例如无法update specific 的attribute而不得不更新整个ObjectQ这个时候性能的差异就会体现出来，只不q大多数情况下，Object不会大到让h无法接受Q也不会像Report query那样request大量的数据，所以这斚w性能的媄响，?STRONG>一?/STRONG>pȝ中不会体现出来?BR>合理划分Query的groupQ真实的目的是减一ơ查询中Join表的个数。Hibernate2的缺陷也可以有所规避Q不能Q意指定Join的方式）
如前所qͼReport query很大E度上被Object Model Design所制约
q有别的一些杂感，例如Hibernate不能support ViewQ动态mappingQ都Ҏ高Performance所能采取的stratagy做了限制。不q这些东西似乎在hibernate3中有了支持，q没有时间用Q不q已l让team里的一个member去research一下hibernate3的new feature
]]>