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

Question

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

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

问候

Answer 1

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

TDG 充当数据库表的(某种)外观 - 并且以表为中心(更改表，您将更改 TDG)。

DAO 是一个抽象 View ，通常表示对象的特定实例(不是整个表，在以表为中心的角度来看——实际上它们根本不是以持久性为中心的)； 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类(class)。因此，围绕数据如何公开的设计决策是由数据源驱动的。

DAO 示例(伪代码)

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

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

Class Purchase
[
   Id
   ItemDescription
   Customer
   DateOfPurchase
]

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

对 DI 至关重要的是 BL 和 DAL 之间的接口(interface)。我们可能会指定一个包含以下内容的接口(interface):

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