。当你需要执行 Statement 对象多次的时候,用 PreparedStatement 对象将会大大降低运行时间,当然也加快了访问数据库的速度。 这种转换也给你带来很大的便利,不必重复 SQL 语句的句法,而只需更改其中变量的值,便可重新执 行 SQL 语句。选择 PreparedStatement 对象与否,在于相同
句法的 SQL 语句是否执行了多次,而且两 次之间的差别仅仅是变量的不同。如果仅仅执行了一次的话,它应该和普通的 Statement 对象毫无差 异,体现不出它预编译的优越性。
软件模型中对数据库访问的设计模式的优化
在我阅读 J2EE 蓝图和 JDO 草案的过程中,我发现了访问模式对数据库访问的影响,因而想在本文中 阐述如何针对自己的软件需求选择合适的软件模式。 J2EE 蓝图的设计者在 Java Pet Store 示例应用中使用了 MVC(Model-View-Controller)体系,给许 多 J2EE 设计模式提供了背景。我要谈及的三种设计模式是:Data Access Object、Fast Lane Reader、 Page-by-Page Iterator,它们为加快数据存取速度提供了一些可以在
系统设计阶段值得我们借鉴的 想法。
Data Access Object
将商业逻辑从数据存取逻辑中分离出来,把存取的资源改编,从而使资源可以容易和独立地转变。
依赖于底层数据资源的特殊要素(例如数据库的供应商)的商业组件,常将商业逻辑和数据存取逻辑 配合起来,只能使用特殊类型的资源,而使用不同类型的资源时,复用将会非常困难,因此,只能服 务于有限的市场领域。DAO(Data Access Object)即是将数据存取逻辑从 EJB 中抽去出来抽象为一 个独立的接口,EJB 根据接口的操作执行商业逻辑,而接口针对使用的数据资源实现为 DAO 对象。 在 Java Pet Shop 这个例子中,OrderEJB 组件通过关联的 OrderDAO 类访问数据库,自身则关注于商 业逻辑的实现。在调度阶段,将配置某一类(OrderDAOCS、OrderDAOOracle 或 OrderDAOSybase)为 OrderDAO 的实现,而 OrderEJB 无须任何更改。图 3 更能帮助你明白其中的道理:
图 3 Data Access Object 的
设计模式 此举增加了数据存取的弹性、资源的独立性和扩展性,但复杂度有相应的提高,其它附带的问题我们 不在这儿讨论。
Fast Lane Reader
抛弃 EJB,加速只读数据的存取。 有些时候,高效地存取数据比获得最新的数据更重要。在 Java Pet Store 中,当一个用户浏览商店 的目录时,屏幕与数据库内容吻合不是至关紧要的,相反,迅速显示和重新获得非常重要。FLR 模式 可以加速从资源中重新获得大型的列数据项的速度, 它不用 EJB, 而是更直接地通过 DAO 来存取数据, 从而消除 EJB 的经常开支(例如远程方法调用、事务管理和数据序列化等) 。 在 Java Pet Store 这个例子中,当一个用户浏览目录时,通过 CatalogDAO(而不是 CatalogEJB)从 数据库加载数据项,而 CatalogDAO 是一个 Fast Lane Reader 的实例,使得读访问变得迅速,如图 4:
图 4 Fast Lane Reader 设计模式 与 DAO 模式不同的是,FLR 是一个优化的模式,但不是要替代原有的访问机制,而是作为补充使
其完 备。当你频繁地只读大型的列数据和不必存取最新的数据时,使用 FLR 将是非常合适的。
Page-by-Page Iterator
为了高效地存取大型的远程数据列,一下子通过重新获得其元素为一个子列的 Value Object(提高 远程传输效率的设计模式,这儿不详尽描述) 。 分布式数据库的应用经常需要用户考虑一长列数据项,例如一个目录或一个
搜索结果的集合。在这些 情况下,立刻提供全列的数据经常不必要(用户并不是对所有的数据项感兴趣)或不可能(没有足够
的空间) 。此外,当重新获得一列数据项时,使用 Entity Bean 的代价将非常高昂,一个开销来自于 使用远程探测器来收集 Requested Bean,另外,更大的开销来自对每个 Bean 产生远程调用以从用户 获得数据。 通过 Ite