J2EE与IBM 对象—对关系数据库系列 （3）

IBM ORDBMS 数据库提供了大量功能，可以简化软件开发，减少硬件需求，以及加快进入市场的步伐。您必须在设计中善加利用，以便从中受益。IBM ORDBMS 不仅仅是一个持久性存储器，更是一条提高您生产率和效率的路径。 非同小可的对象危机 理论上，以及在许多实际案例中，对于持久对象的操作需要实例化该对象，对其进行操作，以及与持久性存储器保持同步。这就导致了容器管理的持久性以及独立于数据库的思想：“使用容器管理的持久性的好处是，实体bean 可以在逻辑上独立于存储该实体的数据源。…” 该规范还提到数据源可以是关系型的，也可以是非关系型的，如 IMS。当然还可以是面向对象的数据库。任何修改容器管理 bean 的交互都需要与该数据源保持同步，以确保实体 bean 的一致视图。对 Enterprise JavaBean(EJB)使用chatty 接口会显著地增加数据库的交互量，从而可能导致性能问题。 “每次实例化一个对象”的中心思想有可能会引起性能和容量问题。该问题不是仅限于容器管理的实体 bean 的使用中，而是普遍存在于面向对象方法中。让我们用一个简单的示例来加以说明。假设有一家专门从事贷款发放的大型银行。它遍及多个区域，每个区域包括几十甚至上百家支行。 图 5. 银行贷款机构 图 5 说明该银行对应多个区域，每个区域都有多个支行，而每个支行又进行多项贷款。它还显示我们可以获得不同种类的贷款。 如果该银行需要获得一份清单，列出那些在贷款中承担了过高风险的支行，它就会按区域来收集该清单。每个区域将搜索其支行，找到那些风险过高的。而支行本身必须查询每一项贷款的风险和贷款额，用以计算该支行的平均风险。 以下是一种适宜的对象方式：每个对象封装自身的信息和处理。支行要获得贷款风险的惟一方法就是向该贷款查询这一信息。该方式比较合理，因为它消除了对象类型之间的紧密耦合。对象间的通信取决于定义良好的接口。只要该接口保持不变，就可以修改其实现，且不影响整个系统。 本例中，如果我们考虑：该银行遍及 10 个区域，每个区域有 100 家支行，而每家支行又有 10,000 份贷款，我们总共创建了1000 万多个对象来响应该查询。要求每份贷款返回两个值：风险级别和贷款额。在区域和支行之间的通信中，这会在两个对象之间传递超过2000 万条消息。最后从内存中删除这些对象需要进行额外处理。 所使用的数目(10/100/10,000)丝毫不过分，我们绝对可以想像将生成更大数量级对象的系统。这很容易成为一个性能以及容量(例如内存)问题。若通过给应用程序服务器增加节点来解决该问题，非但解决不了，反而会增加复杂性。 通过利用 DB2 和 IDS等对象-关系数据库的长处，即使无法消除该问题，也可以有所缓解。请记住，大多数面向对象人员仅仅将数据库看作持久性存储器。他们习惯于将所有处理放在对象的代码中完成，事后才添加数据库。 如果考虑面向对象是何时成为主流的，我们就可以设想，现在绝大多数 30出头或更年轻的程序员已经被训练成以这种方式来思考了。由于数据库仅仅用于“持久保存”对象以及检索它，所以系统开销最小的数据库在该模型中就占有优势。这会有利于层次、网络和对象数据库。而对象-关系型的数据库可以完成比持久保存对象多得多的功能，却成为永远不被启动的大引擎。这就好比是在一场用赛车对抗自行车的比赛中，却不允许您发动引擎一样。 让我们来解释一下：面向对象方法是优秀的。问题在于许多架构师和开发人员视野过于狭隘，不知道可以选择将处理置于何处。这一选择结果会影响设计，并且可以带来重大性能影响。利用ORDBMS的长处可以简化设计，以及极大地提高结果系统的性能。这相当于加快进入市场的步伐，以及降低开发和维护的成本。更快的结果还可以带来重要的商业优势。 数据库独立性 我在前面已提到 J2EE通过促进数据库独立性来提高应用程序的可移植性。并且还进一步提到可以是任何类型的数据库：关系(对象-关系)或非关系的。这是整个J2EE 体系结构的一个美好目标，但在构建商业应用程序中却是一种十分危险的方法。 商业应用程序的目标应该是提供对抗竞争者的商业优势，而非可移植性。可移植性是一个次要目标。如果需要进行移植，可以将不可移植的部分隔离起来，以便限制所需的工作。我们需要以尽可能最低的成本获得尽可能快的响应。如果您针对移植性进行设计，就要设计最底层的功能，从而放弃所有优势。这就像雇主拒绝雇用一个高度称职的人，因为怕他某一天离开，而下一任雇员的能力可能远远不及。按照该逻辑，我们应该雇用最无能的人。否则的话，我们应该确保限制雇员对公司的贡献，这样，如果我们哪天必须用一个逊色一些的人来接替他时，就不会感到失望。期望越多，您将得到越多。而期望越少，您得到的也会随着时间越来越少。 这同样也适用于企业应用程序。您应该权衡您的数据库系统的所有功能，并且对于能够带来商业优势的功能善加利用。您可以在设计中隔离数据库的交互，以便当您偶尔必须迁移到另一数据库时，就只需要完成有限的移植工作。由于数据库的竞争十分激烈，所以，很可能您现在计划使用的独特的新功能将来会出现在某个竞争对手的数据库中。或者，在数据库......