搞ORACLE ERP 的一点感慨

05-11-10 鲁中正气
         

去年,有辛接触了oracle ERP,在这之前,对板桥研究着的这些东西,也是非常感兴趣,陶醉其中,简直有些走火入魔,不过也真有所成,搞了个和板桥这个框架有点类似的东西。然后,带着好奇的心情,虔诚的学习态度,认真学习了ORACLE ERP的技术架构体系,工具,和方法,在几个印度高人的带领下,技术上算是有些门目了,已经进入了比较自在的境界。国庆节,又专门去学了学oracle 的财务模块 实施顾问的课程。
至此,感觉,搞这ERP,什么00,AOP,IOC,乱七八遭的东西都不难,难得的是积累。我看过ORACLE erp 产品的一部分JAVA源代码,感觉其思想古老的很,在代码一级,和BANQ相比,比banq差远了,但是在构件一级,我门就很难超过它。
最大的感慨是如果国家能拿出飞船升天的精力,组织一帮象Banq这样人的来搞个china erp,估计什么SAP,oracle erp,统统很快就会被干掉。

         

1
Kyle_Yin
2005-11-11 01:12

思想如此古老,比BANQ都差远了的 ORACLE, 银行户头居然攥着上百亿美金先进,BANQ都说了,它的时代已经结束了。

这世界,岂不是没天理了?^_^

可见那个先进模式,框架了啥的好像没那么值钱呦~~



》我看过ORACLE erp 产品的一部分JAVA源代码,感觉其思想古老的很,在代码一级,和BANQ相比,比banq差远了

鲁中正气
2005-11-11 09:21

应用范围不一样吧。

鲁中正气
2005-11-11 09:23

光靠banq自己的力量恐怕难以成行。

element
2005-11-16 00:28

ERP架构设计始于业务架构设计,而不是编程框架设计,业务架构设计的好坏是系统设计是否成功的主要因素;因为只有业务架构稳定了,才可能使系统架构获得稳定的基础,即使用再烂的编程架构,也顶多是编程环节多了一部份工作量,也大部分仅限于第一次编程。从长期来看业务架构稳定性的对系统的稳定性贡献是最大的;否则你就是有再好的编程架构,也会疲于应付业务架构的不稳定性――业务对象的不断变化。
编程技术仅仅是整体系统涉及技术的一部分,而且处于下游,各种编程框架、设计模式都有其问题域,但我感觉似乎太小、太细,不能抓住编程框架的元目标――作为共享、抵抗变化等降低成本与提高可靠性的利器。如果脱离应用范围讨论编程框架,我觉得有点无的放矢,毕竟每一类应用的特点不尽相同。oracle erp用的主要技术是主机/终端年代就有的技术(RAD 工具,经过多年的积累,业务层次的稳定性已经很强了),只不过是拿java applet重新作了一个解释器与做了一些java技术包装而已,其核心的业务架构一直是比较稳定的。
建议能把框架讨论与模式讨论能与解决的问题与关联起来,多拿出一些篇幅讨论一下框架与模式对终极目标(给开发商、用户带来的价值)的贡献。
初来乍到,如有冒犯,请多包涵。

4Go 1 2 3 4 下一页