去年，有辛接触了oracle ERP，在这之前，对板桥研究着的这些东西，也是非常感兴趣，陶醉其中，简直有些走火入魔，不过也真有所成，搞了个和板桥这个框架有点类似的东西。然后，带着好奇的心情，虔诚的学习态度，认真学习了ORACLE ERP的技术架构体系，工具，和方法，在几个印度高人的带领下，技术上算是有些门目了，已经进入了比较自在的境界。国庆节，又专门去学了学oracle 的财务模块 实施顾问的课程。
至此，感觉，搞这ERP，什么00，AOP,IOC,乱七八遭的东西都不难，难得的是积累。我看过ORACLE erp 产品的一部分JAVA源代码，感觉其思想古老的很，在代码一级，和BANQ相比，比banq差远了，但是在构件一级，我门就很难超过它。
最大的感慨是如果国家能拿出飞船升天的精力，组织一帮象Banq这样人的来搞个china erp,估计什么SAP,oracle erp,统统很快就会被干掉。
思想如此古老，比BANQ都差远了的 ORACLE， 银行户头居然攥着上百亿美金先进，BANQ都说了，它的时代已经结束了。
这世界，岂不是没天理了？^_^
可见那个先进模式，框架了啥的好像没那么值钱呦～～
》我看过ORACLE erp 产品的一部分JAVA源代码，感觉其思想古老的很，在代码一级，和BANQ相比，比banq差远了
应用范围不一样吧。
光靠banq自己的力量恐怕难以成行。
ERP架构设计始于业务架构设计，而不是编程框架设计，业务架构设计的好坏是系统设计是否成功的主要因素；因为只有业务架构稳定了，才可能使系统架构获得稳定的基础，即使用再烂的编程架构，也顶多是编程环节多了一部份工作量，也大部分仅限于第一次编程。从长期来看业务架构稳定性的对系统的稳定性贡献是最大的；否则你就是有再好的编程架构，也会疲于应付业务架构的不稳定性――业务对象的不断变化。
编程技术仅仅是整体系统涉及技术的一部分，而且处于下游，各种编程框架、设计模式都有其问题域，但我感觉似乎太小、太细,不能抓住编程框架的元目标――作为共享、抵抗变化等降低成本与提高可靠性的利器。如果脱离应用范围讨论编程框架，我觉得有点无的放矢，毕竟每一类应用的特点不尽相同。oracle erp用的主要技术是主机/终端年代就有的技术（RAD 工具，经过多年的积累，业务层次的稳定性已经很强了），只不过是拿java applet重新作了一个解释器与做了一些java技术包装而已，其核心的业务架构一直是比较稳定的。
建议能把框架讨论与模式讨论能与解决的问题与关联起来，多拿出一些篇幅讨论一下框架与模式对终极目标（给开发商、用户带来的价值）的贡献。
初来乍到，如有冒犯，请多包涵。
欢迎，欢迎！
element 也在搞ORACLE ERP？有空多来灌灌水。
我前一阵刚参加了个培训，学学了oracle的功能架构，目前正在思考阶段，由于它涉及的各行业知识太多，现在感觉要学的东西还很多。
> 去年，有辛接触了oracle
> ERP，在这之前，对板桥研究着的这些东西，也是非常感兴趣?> 陶醉其中，简直有些走火入魔，不过也真有所成，搞了个和板
> 耪飧隹蚣苡械憷嗨频亩鳌Ｈ缓螅藕闷娴男那椋系难
> 习态度，认真学习了ORACLE
> ERP的技术架构体系，工具，和方法，在几个印度高人的带领?> ，技术上算是有些门目了，已经进入了比较自在的境界。国庆
> 冢肿湃パЯ搜oracle 的财务模块 实施顾问的课程。
> 至此，感觉，搞这ERP，什么00，AOP,IOC,乱七八遭的东西都
> 荒眩训玫氖腔邸Ｎ铱垂ORACLE erp
> 产品的一部分JAVA源代码，感觉其思想古老的很，在代码一级
> BANQ相比，比banq差远了，但是在构件一级，我门就很难?> 过它。
> 最大的感慨是如果国家能拿出飞船升天的精力，组织一帮象B
> nq这样人的来搞个china erp,估计什么SAP,oracle
> erp,统统很快就会被干掉
人家积累那么多年的代码了，能不古老么。等我们带人搞出来了，再有人看我么的代码一样古老。
ERP这种东西不能看代码有多么优美吧……
这个问题的答案很简单：就是因为 ORACLE ERP 的框架严重恶心，导致用户怨声载道，所以 ORACLE 最终不得不靠收购来实现在应用领域的扩张。
呵呵。
>
> 建议能把框架讨论与模式讨论能与解决的问题与关联起来，?
> 拿出一些篇幅讨论一下框架与模式对终极目标（给开发商、用
> Т吹募壑担┑墓毕住?
> 初来乍到，如有冒犯，请多包涵。
>ORACLE ERP 的框架严重恶心，导致用户怨声载道
这个我赞同，Oracle是靠数据库出其不意暴发，它有数据库包袱，又没有深厚的软件设计功底，所以他的中间件产品都是变相将用户向数据库诱导，典型的打着红旗反红旗。
呵呵，终于找到共同语言了。
ORACLE 新的应用框架，所谓 FUSION ADT，感觉还是恶心。压根就是原来那些东西，拼凑到一起起个新名字就充数。这么复杂的东西，实在看不出比J2EE规范方便到哪里去，当作内部工具也就罢了，外部客户要是拿来写应用那根本是给自己找堵。既然要用那么复杂的框架，我干吗不用标准J2EE API？至少还能保持平台兼容。用了ADT既不减少工作量，又绑定在ORACLE身上。傻啊？
ORACLE 在应用框架方面的根本方向仍然是错误的。
以前有个客户找我培训J2EE，说是最热门的技术，然后那个传话的人还没说清楚，说成JDT，说是搞Java的人听到这个名词就知道，我就没想到ADT，以为是JSF呢，结果，我知道那个客户给Oracle误导到没治的地步了，我跟他们说：你们要好好从J2EE开始培训，结果他们可能认为我水平不行，ADT都不知道，我这个堵啊！
我不是想诽谤oracle等公司，但是我做一做“Java技术大侠”还是可以，不从经济利益为谁讲话，只从客观 至少我认为客观角度谈论。
不过，听说下一个版本的oracle erp 将安全采用j2ee架构，具体什么样，不知道。即便是推出了，估计用户也很少用吧，毕竟用户以前投入了这么多了。据我所知，原来搞ORACLE 二次开发的人对J2EE精通的也很少。
现在大家都正在学J2EE的各种技术，以配合ORACLE的转型，有个印度的，年龄挺大了，吓得去做EBS DBA了，呵呵，其实还是做EBS DBA好。
〉ERP架构设计始于业务架构设计，而不是编程框架设计
业务框架是否稳定不取决于我们搞编程的吧。即使业务建模工作再到位，也架不住“某部委的一纸文件”。河北省搞了一个信息交换平台，其实就是把数据挖掘和数据仓库技术改头换面，目的就是为了“一个稳定的业务框架”，因为这种另类的数据库结构（表被旋转），“添加一个字段”这样的工作就变成“添加一条记录”了。本来数据仓库是用来做统计分析和决策支持（OLAP）的，结果被几个人搞成作业务系统（OLTP）的，KAO，真是天才呀！
为啥搞oracle ERP的要精通j2ee?
作SAP顾问连 java都不会也很正常。