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

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

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

---

在我看来，主要区别在于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
]

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

对于DI来说，最重要的是BL和DAL之间的接口；我们可以指定包含以下内容的接口：

GetPurchaseDetails() - returns a PurchaseDetails object

我们定义的

PurchaseDetails

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

---

另一种观点见：

好，但技术上有什么区别？你能给出一个简短的代码示例来说明这种差异吗？与其说是技术上的差异，不如说是一种方法；这更多的是围绕控制权所在的有意识决策（在指导设计和设计决策方面）。我将对我的回答作更多的解释。@AdrianK，我认为你描述的是一个对象，而不是一个数据访问对象。据我所知，DAO与数据库紧密耦合。@David，你可能就在那里。这篇文章最初是在2010年发布的，但我想在那个时候事情不会有太大的变化吗？@AdrianK是的，这篇文章肯定很老了，但仍然相关。我的copyright 2003副本描述了一个数据访问对象，它“封装了对持久数据存储的所有访问”

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