在面向对象的应用中，持续性允许一个对象的寿命可以超过创建它的程序。这个对象的

状态可能被存储到磁盘上，并且在将来的某一时刻相同状态的对象可以被重新创建。

这样的应用不仅仅限于简单的对象——关联对象的完整图形也可以被持续化并且以后可以在新的进程里被重新创建。大多数对象并不是持续性的；暂态对象只有有限的寿命，被实例化它的进程的寿命所限定。几乎所有的Java应用都在混合使用持续与暂态对象；因此，我们需要一个子系统来管理我们的持续性数据。

现代的关系数据库为持续性数据提供了一种结构化的表示方法，允许排序，检索和合计

数据。数据库管理系统负责管理并发性和数据的完整性；它们负责在多个用户和多个应用之

间共享数据。数据库管理系统也提供了数据级别的安全性。

我们考虑以下这些事情：

1 存储，组织与恢复结构化数据

2 并发性与数据完整性

3 数据共享

特别地，我们将在使用域模型的面向对象的应用环境中考虑这些问题。

使用域模型的应用并不直接使用业务实体的扁平表示进行工作，这些应用有它们自己的

面向对象的业务实体模型。如果数据库中有“项目”与“竞价”表，则在这些Java应用中会定义“项目”与“竞价”类。

然后，业务逻辑并不直接在SQL结果集的行与列上进行工作，而是与面向对象的域模型进行交互，域模型在运行时表现为一个关联对象的交互图。业务逻辑从不在数据库中（作为SQL存储过程）执行，而是被实现在Java程序中。这就允许业务逻辑使用成熟的面向对象的概念，例如继承与多态。我们可以使用众所周知的设计模式例如“策略”，“中介者”和“组合” ，所有这些模式都依赖于多态方法调用。现在给你一个警告：并不是所有的Java应用都是按照这种方式设计的，并且也不打算是。对于简单的应用不使用域模型可能会更好。SQL和JDBC API可以完美地处理纯扁平数据，并且现在新的JDBC结果集已经使CRUD操作变得更简单了。使用持续性数据的扁平表示进行工作可能更直接并且更容易理解。

然而，对于含有复杂业务逻辑的应用，域模型有助于有效地提高代码的可重用性和可维

护性。通常Hibernate和ORM总是与这种类型的应用有关。

如果我们再次考虑SQL和关系数据库，我们最终会发现这两种范例的不匹配之处。

SQL操作例如投射与连接经常会导致对结果数据的扁平表示。这与在Java应用中用来执行业务逻辑的关联对象的表示完全不同！这是根本不同的模型，而不仅仅是相同模型的不同的显示方式。

带着这些认识，我们能够开始看一下这些问题——许多已经很好理解的与没有很好理解的——必须被合并使用这两种数据表示的应用所解决——一个面向对象的域模型与一个持续性的关系模型。让我们仔细地看一下。

评论 (0) All

登陆 还没注册？