表数据网关和数据访问对象的体系结构差异

在我看来,主要区别在于TDG以数据库(持久性)为中心,而DAO以业务/对象实例为中心。

TDG充当数据库表的外观(某种程度上),它以表为中心(更改表,然后更改TDG)。

DAO是一个抽象视图,通常表示一个对象的特定实例(不是整个表,在以表为中心的透视图中——事实上,它们根本就不是以持久性为中心的);DAO通常是围绕业务概念设计的。

在您只需要在数据库之上构建一个访问层的情况下,TDG将非常有用——在这个情况下,项目完全与数据库有关(为其他应用程序获取对它的访问权限等等,比如说一个遗留系统)。

DAO将用于更“正常”的情况,在这种情况下,您将从头开始构建一个新的以业务/逻辑为中心的解决方案。

TDG示例(伪代码)

您的起点是数据库,例如:一个包含3行数据的表:

ContactsTable
--------------------
Id | Name | Ph 
--------------------
01 | Bob  | 192837
02 | Joe  | 564738
03 | Ali  | 483957

您的下一步将是构建一个处理物理数据访问的代码层,您返回的数据不会比表提供的多也不会少。如果您有多个表,它们将分别显示(i 认为 -我需要检查)。作为数据的使用者,您必须将逻辑中的内容(在TDG本身之外的代码中)连接起来。

代码返回数据的方式在很大程度上取决于您——您甚至可以使用一个对象:

Class ContactTableRecord
[
   Id
   Name
   Ph
]

因此,现在您可以用代码表示数据;您的应用程序可以使用它喜欢的数据。但是,如果数据库结构发生变化,您还需要更改代码层以匹配-在本例中, ContactTableRecord 班级。因此,围绕数据如何公开的设计决策是由数据源驱动的。

DAO示例(伪代码)

首先,您将围绕客户、许可证、许可证、购买、背书、位置等概念设计您的系统;然后(可能)建模这些概念之间的关系。假设我们在核心业务逻辑中有一些类,我们定义为:

Class Customer
[
   Id
   Name
   Ph
   Purchases
   ListAllPurchases()
   SendInvoice()
]

Class Purchase
[
   Id
   ItemDescription
   Customer
   DateOfPurchase
]

到目前为止,我们还没有访问任何数据,我们甚至可能不知道我们的数据源将是什么。如果我们提前考虑,我们将使用 Dependancy Inversion (DI)。

DI最重要的是BL和DAL之间的接口;我们可以指定一个包含如下内容的接口:

GetPurchaseDetails() - returns a PurchaseDetails object

这个 PurchaseDetails 我们定义的对象,我们打算在BL和DAL之间传递,或者在我们的应用程序和另一个应用程序之间传递的对象是DAO,它是构成购买和客户的数据的表示。因为它的重心是BL,所以它不受数据库结构的约束(事实上,我们还没有做到这一点——我们不需要让DAO存在)。

// This is our DAO: 
Class PurchaseDetails
[
   CustomerId
   Name
   Ph
   PurchaseId
   ItemDescription
   DateOfPurchase
]

另一种观点见: Table Data Gateway vs. Data Access Object