基于oracle8i的编程模型之比较(我认为很经典,就摘下来了)
发表时间:2024-05-24 来源:明辉站整理相关软件相关文章人气:
[摘要]第一类:以组件为基础的开发 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的解释型执行方式快得多!