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

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

1 个答案: