Oracle BAM 使用体会
看了一下BIRT。 想起在前一家公司使用Oracle BAM, 当时就我一个人搞BAM,从零开始,把东西学的差不多后发现Oracle BAM要做起应用
看了一下BIRT。 想起在前一家公司使用Oracle BAM, 当时就我一个人搞BAM,从零开始,把东西学的差不多后发现Oracle BAM要做起应用来极其崩溃,几乎要把我折磨死。Bug一堆不说,功能设计也相当鸡肋。虽然可以理解,做到Oracle BAM那么不编程就实现实时确实很难,但是感觉Oracle的设计方向有问题。把东西封装的太死,花大量时间做功能的封装,几乎没有任何扩展,这样的好处是如果只用到了它提供的功能,万事大吉,做的还快,但是一旦它的功能没法满足需求,那么就完蛋了。
1.Report的产生只能按照BAM提供的套路,直接从DataObject里生成,提供的套路有限。大概就是sql功能的限制版,限制只能在一个DataObject上操作。 经常遇到的问题是,为了某个report建了一个DataObject; 之后的需求要用同样的数据生成另外的report,但是因为BAM提供的套路有限,可能这个时候的数据格式就没法生成我们要的report了,就只能再建一个DataObject。造成大量数据重复,集成复杂化。BAM对比BIRT的一个不足是,BIRT可以从一个SQL的执行结果里生成report,这样SQL就可以对数据进行一些预转换来满足业务要求。BAM没有类似的功能,考虑到BAM需要截获数据的变更,所以通过sql来做确实有点困难,但是还是希望有个类似的功能出来。
2.Report的style只能在页面上的那些选择之类来更改,没有一个统一的CSS。 这样如果大老板希望所有report的颜色之类变变,那就只能把自己当苦力,一个一个改了。当时确实碰到这个问题,好在被TL挡住了,不然要累死。
3.BAM提供一个基于web的report编辑器。report里的view的布局之类也在web上做,用鼠标托拉调整大小,对齐之类。没有提供任何帮助的工具,没有坐标,没有水平线,垂直线,百分比,或者直接输入值的地方。反正什么都没有,,想要把页面布局的好看些那就哭去吧。好在后来我做了个小工具,把report先导出来,导出的文本其实是个XML,把report内容的部分截出来,把< > & 之类的字符按XML转义的替换一下,生成一个新的xml,直接更新xml的内容,可以直接调整大小,颜色之类。完了把字符替换回去,并入原来的XML再导入到BAM。
4.动态性不足,没有地方让用户可以自己输入javascript之类来对页面进行些自定义的操作。虽然BAM生成的也是html,但是Oracle把这些都封装死了,没法潜入javascript ;再比如calculator field,其实也可以做到用写动态语言自己写,现在只能用BAM的功能,就算对字符串进行简单操作都变得很困难。
5.bug太多,产品还不够稳定;封装太死,提供的功能的一致性不够强。很多我们认为它会提供的功能最后发现没有,做任何事情前都要亲手做一下,切切实实的试试才能知道到底能不能做。比如,一个Row Group里面不能包含另外一个Row Group; Row Group的title字体没法改(可以用3里提到的那个工具改);Drill Across的参数不能含有 ‘,’(BAM在javascript里写死用这个作为参数分隔符);Drill Across不能用Calculator field作为参数等等。
上一篇: MySQL备份和同步时使用LVM
下一篇: PHP设计模式漫谈之工厂模式