表数据网关和数据访问对象架构差异

Question

有人可以描述表数据网关（TDG）和数据访问对象（DAO）之间的主要区别吗？

TDG 可以操作该表的所有行，但 DAO 也可以（DAO 可以保存、删除指定对象，也可以对整个表进行操作）

问候

Answer 1

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

TDG 充当数据库表（某种意义上）的外观 - 并且以表为中心（更改表，您就会更改 TDG）。

DAO 是一个抽象视图，通常表示对象的特定实例（不是整个表，从以表为中心的角度来看 - 事实上它们根本不是以持久性为中心的）； DAO 通常是围绕业务概念设计的。

TDG 在您只需要在数据库之上构建访问层的情况下非常有用 - 该项目全部与数据库有关（为其他应用程序等访问它 - 比如说遗留系统）。

DAO 将用于更“正常”的情况，即您从头开始构建新的以业务/逻辑为中心的解决方案。

TDG 示例（伪代码）

您的起点是数据库，例如：包含 3 行数据的表：

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

您的下一步将是构建一个处理物理数据访问的代码层，并且您返回的数据不会多也不少于表提供的数据。如果您有多个表，它们将单独暴露（我认为 - 我需要检查）。作为数据的使用者，您必须将逻辑中的内容（在 TDG 本身之外的代码中）连接起来。

代码如何返回数据很大程度上取决于您 - 您甚至可以使用对象：

Class ContactTableRecord
[
   Id
   Name
   Ph
]

现在你有了代码中数据的表示；您的应用程序可以随心所欲地使用数据。但是，如果数据库结构发生变化，您还需要更改代码层以匹配 - 在本例中为

ContactTableRecord

类。因此，围绕如何公开数据的设计决策是由数据源驱动的。

DAO 示例（伪代码）

首先，您将围绕概念设计系统 - 例如客户、许可证、许可证、购买、认可、位置等；然后你（可能）会建模这些之间的关系。假设我们的核心业务逻辑中有一些类，我们将其定义为：

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

Class Purchase
[
   Id
   ItemDescription
   Customer
   DateOfPurchase
]

到目前为止，我们还没有访问过任何数据，我们甚至可能不知道我们的数据源是什么。如果我们提前考虑，我们将使用 Dependency 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
]

有关其他意见，请参阅：表数据网关与数据访问对象