На мой взгляд, основное отличие состоит в том, что TDG ориентирован на базу данных (постоянство), а DAO ориентированы на экземпляр бизнес / объекта.
TDG действует как фасад (своего рода) для таблицы базы данных - иориентированный на стол (измените таблицу, и вы бы изменили TDG).
DAO - это абстрактное представление, обычно представляющее конкретный экземпляр объекта (не всю таблицу, с точки зрения таблицы - фактически они вообще не ориентированы на постоянство);DAO часто строятся вокруг бизнес-концепций.
TDG будет полезен в ситуациях, когда вам просто нужно создать уровень доступа поверх базы данных - когда проект полностью связан с базой данных (получение доступа к нему для другихприложения и т. д. - скажем, устаревшая система).
DAO будут использоваться в более «нормальных» ситуациях, когда вы создаете новое решение, ориентированное на бизнес / логику, с нуля.
Пример TDG (псевдокод)
Отправной точкой будет база данных, например: таблица с 3 строками данных:
ContactsTable
--------------------
Id | Name | Ph
--------------------
01 | Bob | 192837
02 | Joe | 564738
03 | Ali | 483957
Следующим шагом будет создание слоя кода, который обрабатывает физический доступ к данным,и возвращаемые вами данные будут не больше и не меньше, чем то, что предлагает таблица.Если у вас есть несколько таблиц, они будут выставлены отдельно (я думаю - мне нужно проверить).В качестве потребителя данных вам придется объединить вещи в своей логике (в коде вне самой TDG).
То, как ваш код возвращает данные, в значительной степени зависит от вас - вы могли бы даже использоватьobject:
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
]
Другое мнение см .: Шлюз табличных данных и объект доступа к данным