[摘要]第一类：以组件为基础的开发 vs. 存储过程目前，“以组件为基础的编程”很快成为许多人首选的应用程序开发方案。它能将来自不同厂商的组件有机结合到一起，允许代码重复使用，并易于维护，易于展开，易于扩展，从而快速开发出应用程序。适合采用以组件为基础的开发模型的应用程序包括：■ 计算密集型应用：假如一个...
第一类：
以组件为基础的开发 vs. 存储过程
目前，“以组件为基础的编程”很快成为许多人首选的应用程序开发方案。它能将来自不
同厂商的组件有机结合到一起，允许代码重复使用，并易于维护，易于展开，易于扩展，从
而快速开发出应用程序。适合采用以组件为基础的开发模型的应用程序包括：
■ 计算密集型应用：假如一个应用程序需要进行密集的逻辑运算和算术计算，那么来自
第三方的组件，以及组件的重复利用能力，可使整个开发过程变得更加容易。
■ 复杂的多层次应用：对O r a c l e 8 i内运行的E J B和C O R B A组件来说，它们通过I I O P，可自
I n t e r n e t浏览器、C O R B A客户机以及纯J a v a客户机中方便地调用。D C O M客户机（如
Microsoft Transaction Server上运行的Visual Basic应用程序）可通过一个D C O M→
C O R B A桥，方便地访问C O R B A服务器。
另外，适合采用存储过程开发的应用程序包括：
■ S Q L密集型应用：存储过程与数据库高度集成，所以特别适合经常要通过S Q L访问数
据的应用程序。
■ 传统双层应用：存储过程为传统双层应用程序提供一个简单、直接的编程模型。
O r a c l e 8 i内的存储过程可用一系列数据库客户机方便地访问，比如J D B C、S Q L J、
O D B C、O C I和O r a c l e开发客户机等等。
第二类：
以组件开发为基础的： EJB vs. CORBA
E J B技术使我们能更易在一个C O R B A基础结构的顶部，构建J a v a应用程序。如同本章
“E J B的优点”一节详细讲述的那样， E J B通过覆盖一个更高级别的编程接口，从而实现对
C O R B A的引用。E J B是完全用J a v a写成的，不必使用I D L。E J B事务处理和安全策略通过声明
的方式加以指定，而不是以程序化的形式。
C O R B A对象可在需要良好粒化的功能时，进行编写。O r a c l e 8 i配套提供的C a ff e i n e（咖啡
因）工具可有效地降低用J a v a开发C O R B A服务器时牵涉到的一些复杂性。
注意尽管C O R B A对象可用任何语言写成，但只有用J a v a写成的对象，才能在
O r a c l e 8 i内展开。
第三类：
存储过程： PL/SQL vs. Java
P L / S Q L与数据库紧密集成具有下述优点：
■ 对S Q L具有自动可见性：在P L / S Q L中，毋需任何条件，所有进程和函数在S Q L面前都
是显露无遗的。而在J a v a中，首先必须编写对应的调用规范，发布那些希望S Q L“看见”
的方法。
■ 能有效地访问S Q L：在S Q L密集型应用中（亦即需要频繁地读写数据表），P L / S Q L的表
现比J a v a存储过程好。这是由于P L / S Q L支持与S Q L相同的固有数据类型。O r a c l e并未
在数据库内部直接提供对固有J a v a类型的支持。只有S Q L类型和与对象相关的类型才能
保存在数据库内。因此，假如需要从一个J a v a存储过程中访问数据库， O r a c l e必须将
J a v a类型转换成S Q L数据类型（反之亦然）。显然，这会造成对执行效率的影响。而且
在某些情况下，这样的转换还会造成精度的下降。
注意在J a v a存储过程中，假如随o r a c l e . s q l数据类型（而非标准J a v a类型）使用S Q L
数据，那么应注意到效率和精度的提高，详情可参考第9章。但缺点在于： J a v a代码
将丧失移植类型，因为o r a c l e . s q l类型仅适用于O r a c l e。
针对I n t e r n e t及I n t r a n e t应用的开发， J a v a正在快速成为一种流行的语言。除此以外， J a v a
也正在成为存储过程开发的首选语言。对O r a c l e 8 i来说， J a v a和P L / S Q L存储过程相互间是可
以“交互操作”的。因此，以前在P L / S Q L代码上的投资不会被无谓地浪费掉。
下面列出一系列典型属性，正是由于它们，使得J a v a成为存储过程开发的一种最佳语言：
■ 移植能力： J a v a存储过程可在来自多家厂商的数据库间自由移植。而在另一方面，
P L / S Q L仅适用于O r a c l e。从理论上说，我们可将来自另一个数据库厂商的J a v a存储过
程方便地移植到O r a c l e环境：只需在数据库内装载J a v a源码或二进制数据，然后将它们
发布给S Q L就可以了。
■ 真正的面向对象支持： J a v a在设计之初，就被定义成一种真正的“面向对象”程序设
计语言。P L / S Q L则不同，它最开始的时候仅仅是一种程序化的编程语言，同数据库紧
密集成，只是现在增加了部分面向对象的语言特性。
■ 丰富的库和工具支持： J a v a比P L / S Q L提供了多得多的函数库，以及第三方的开发工具
支持。
■ 一种万能语言，支持所有层面的开发： J a v a是一种“万能型”语言。一种语言便可适
用于所有层面的开发：客户前端的应用程序和小程序（ A p p l e t），服务器后端的服务器
小程序（S e r v l e t）和数据库存储过程等等。因此，采用J a v a编程，可有效降低培训和开
发成本。
■ 本地编译好的库：在那些计算密集型的应用程序中，以及那些包含了少量数据库读写
操作的应用程序中， J a v a存储代码的运行速度都要快于对等的P L / S Q L代码。这是由于
j a v a . l a n g封装和其他s y s所有的封装是在“本地”编译好的；或者说，是“固有”的。
J a v a存储过程在调用本地编译代码时，速度当然比P L / S Q L的解释型执行方式快得多！
……