表数据网关和数据访问对象架构的区别

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
]

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