经验之谈：对于OAF与struts的一些浅薄看法 (转载于 深山老僧)

gaoyiming

对于OAF与struts的一些浅薄看法      经过项目上的洗礼，我对于MVC概念有些深入的了解，在此介绍两种框架，与大家分享一下。      时下ERP软件趋向web是一个潮流，因为B/S架构于C/S架构相比，凭借着夸平台性等优势使得原版庞大的ERP一下子瘦身，屏弃了客户端，我们只要有web浏览器就能使用软件。struts本身就是MVC的典型代表，许多其他框架都从它发展开来。而OAF是oracle公司2004年推出的全新B/S架构ERP。接下来我从MVC不同层次来分析一下两者的特点。      首先View:struts的页面是标准的Jsp，由于有struts标签以及JavaScript支持，页面可以自由设置更改，自主性较强。不过有时候太自由也不太好，今天我注意到页面上标题栏莫名地多了一行，使得页面看起来非常不协调，这要是交货的话，肯定要被指摘。所以我硬着头皮花了个把小时检查Jsp，但还是一筹莫展，撑到十点，罢了，明天再搞，随后灰溜溜地回来了。实际上我最怕动Jsp，就怕哪里多个标签什么的，使得编译过不了。因此开放的Jsp使得出错可能性大大增加。而OAF的页面恰恰相反，完全是封装过的Jsp。没有标签，只有控件。这使得OAF做页面更像是VB，而不是Jsp。由于是封装过的，这使得OAF做出来的页面都非常死板，整个页面被分成规定的几部分，在OAF框架下，没有个性，不容许你做出实现功能以外部分，事实上你也没有可能做出来。因为OAF就是为ERP而开发的。这与做普通网页有本质区别。     其次是Controller: struts对于页面的控制是通过action进行的。对于event的捕捉也比较灵活。一个event对于一个Java类，这样的搭配非常一目了然。在业务逻辑上，struts从下至上又分为data层，function层，page层。个人认为这样的结构层次分明，简便，但对于复杂的页面来说，将形成庞大的Java类，不易维护。OAF通过CO控制页面，CO又包含processRequest与processFormRequest两个method，分别控制initialize以及event。但是我觉得对于复杂页面，OAF处理event稍显麻烦，试想大量的event集中在一个method里面控制，而struts却是对一个event对于一个class，哪个更复杂，已经很明了了。但是有失必有得，OAF这样的设置，对于页面的变换控制能力比struts更胜一筹，因为struts必须依靠JavaScript来控制，这样代码量惊人，非常不易维护。从业务逻辑上，OAF从下至上分PL/SQL，AM。struts对于数据的操作，是通过简单SQL语句进行的，需要频繁访问DB，经常一次业务对DB进行十几次操作，试想一下，要是瞬时访问量巨大的话，系统非常容易崩掉。所以对于访问量巨大的软件来说，这样的架构是非常不合适的。而这点却完全体现oracle在数据库上的强大能力。OAF通过PL/SQL在DB Server进行业务处理，省去了大量的与web Server之间的通讯，减少了web Server的访问压力，这对于超大型软件是非常合适的。但是OAF规矩的格式，使得对于transaction的处理非常不灵活，不能自由控制transaction，这增加了对页面控制 的难度。而struts，则能够自由控制，完全不用担心。      最后是Module：struts的模型相当简单，仅仅是JavaBean，我想我找不出更多的理由来说明它。相反，OAF的模型非常完善，分成ViewObject,EntityObject。我觉得OAF的风格更接近EJB，简便分散的struts对于复杂业务的把握能力远比不上OAF，复杂的模型对于复杂的业务更具大局观。     进过以上分析，或许你会想哪种框架更优秀？实际上这两种框架的风格完全相反，struts结构简单，分散，自由；而OAF结构复杂，紧密，拘束。这正好比问公共汽车好，还是豪华大巴好。因为它们在不同作用域里起着不同作用，正如高低搭配，是不能相互取代的。感觉还是挺有意思的！哈哈

atomic79

说的好！不得不顶！

freeya

声明一下：

这个可不是我说的，这也是我在网上找到的，转载在我的百度吧里的，版主在转回来的时候看来时没有注意，把我的名字给写上去了，惭愧呀，

孤心泪

JSP都不敢动，说明WEB编程和JAVA编程功底严重不足
Struts的灵活性比OAF强多了，OAF强势不在于VIEW层，其实并没明显的优势，最明显的优势就是和ERP的整合和不用关闭数据库连接

atomic79

JSP都不敢动??你是说OAF吗？

kof_killer

还是觉得struts比较灵活好用