古人云：温故而知新。在讨论新的数据访问模式之前，我们先来回忆一下上一篇Post中提到的Data Accessor模式吧。 Data Accessor提供了一种解耦合的策略：将数据库访问的细节进行逻辑抽象并封装于单一组件中，从而降低数据访问和数据模型之间的耦合性。对于应用程序而言，它并不了解具体的数据访问操作，如建立数据库连接和执行SQL语句等，但是它仍然了解数据模型的具体结构，譬如数据表名和某一数据表的列名等。因此，应用程序虽然脱离了数据访问的烦恼，但仍然与数据模型紧密耦合在一起。如果数据模型发生改变，或者数据模型的建立并非通过静态描述即可完成的，都会令应用程序不得不面临大范围的改动。在这个时候，Active Domain Object(主动域对象，以下大部分地方简称ADO)模式就可以大展身手了。 ADO模式的实质很简单，就是将数据模型的细节也封装在单一组件中，对应用程序仅公开与业务逻辑相关的通用操作。我们之所以把这样的对象称为Active，正是因为对象本身包含了数据模型和与业务逻辑相关的数据访问操作，而不仅仅是数据的载体(如果将数据访问的代码剥离，那么Active Domain Object就会退化成Domain Object/Value Object)。从这个角度出发，上一篇Post中给出的代码已经无意中使用了与ADO十分类似的模式：
根据自己参与过的一个项目的经验，UserDAO中可以包含很多与业务逻辑相关的方法，例如getVIPUser等。如果UserDAO本身包含了User的属性，并将UserDAO改为User，UserDAO摇身一变就成为了一个Active Domain Object变体。但是这样的UserDAO并非是一个纯粹的Active Domain Object，因为其包含的逻辑操作并不是通用的操作。通常，定义在一个Active Domain Object的通用操作主要有四个方面： 1、初始化(Initialize)：读取一个或多个数据表以初始化Domain Object的内容； 2、刷 新(Refresh)：当数据表发生更新之后，通过这样的操作以更新Domain Object的内容； 3、保 存(Save)：将Domain Object内容的改变持久化至数据表中； 4、列 表(List)：根据查询条件获得所需的单个Domain Object或者Domain Object集合。有了这样四个方面的操作，我们可以将应用程序中的业务逻辑看作是若干个Active Domain Object的若干次通用操作的组合体。在这样的前提下，应用程序的业务逻辑将会更加的清晰，而便于维护。同时将应用程序和数据模型解耦合了，即使数据模型发生了改变，应用程序的改动也将会是很小的。 ADO模式的思想很好理解，但是要建立一个满足应用程序需求的Active Domain Object就并非易事了，会有很多问题需要考虑：譬如，Domain Object的创建是否仅仅以单表作为依据呢？还是需要建立与联接表对应的Domain Object呢？Domain Object的属性是不是就简单的引入一个表中的所有列呢？对应用程序而言，仅仅是逻辑操作是可见的，那么Active Domain Object封装的与逻辑操作相关的数据访问性能是否足够好呢？诸如这类问题都是在设计和实现Active Domain Object的时候要深思熟虑的。[1] 参考书籍：《数据访问模式——面向对象应用中的数据库交互》
Powered by: 博客园 Copyright © FantasySoft
