11

Put simply about Table Data Gateway (TDG) implementation: you create separate TDG class that contains SQL for CRUD operations with concrete table. So, your models communicate not directly with a datasource (for example database) but via those abstracted ones - TDG classes. So, it's just an approach for making another level of abstraction and it's just a wrapper for communicating with database - get and modify the data. IMHO TDG classes should not contain members, only methods. Here's a good schema that visualizes the use TDG pattern. When using TDG approach, SQL should be moved from model classes to datasource (TDG) classes. And all data that I retrieve from DB through TDG classes are stored in my model members.

Now, what about active record implementation? If I would merge data access and my model class into one model class then would I implement active record? I was unable to find a clear distinction or how those patterns look in PHP and differ from each other.

Often, I'm having one singleton database class and then separate model class for each database table. Each model class has CRUD + several custom (count, avg and etc.) operations. Some classes have members for persisting results from CRUD or custom operations - thats's done upon the need. Could this approach be identified as active record? Also, if I would move SQL from my model classes to TDG classes would this be Table Data Gateway?

Community
  • 1
  • 1
Centurion
  • 14,106
  • 31
  • 105
  • 197

1 Answers1

15

From http://martinfowler.com/eaaCatalog/index.html

Table Data Gateway: An object that acts as a Gateway (466) to a database table. One instance handles all the rows in the table.

enter image description here

Active Record: An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

enter image description here

The obvious main difference is that TDGs wrap access to a table and only returns row data, while ARs wrap access to a row in the table and adds business logic to it.

Unless you have very low impedance mismatch, having a TDG is preferred because with AR your business/domain objects follow the structure in the database, which us usually not how your domain objects should be modeled. A Row may know how to persist itself, but a Person should not know. It is more maintainable in the long run to to separate persistence logic and domain logic.

Regarding your Singleton DB object have a look at Is there a use-case for singletons with database access in PHP?.

Community
  • 1
  • 1
Gordon
  • 312,688
  • 75
  • 539
  • 559
  • Thanks. What types of methods (and SQL queries) I might have when implementing TDG? I should not put business logic but what might be considered a business logic stuff? For example, can I have such methods (and SQL queries) in TDG classes like selectAllRows, batch update (pass an array of data), selectAllPersonsByLastName, countAll, SelectAvg and etc? IMHO all of them should reside in TDG class. Does business logic stuff means any additional calculations made from the derived SQL result set from TDG class? – Centurion Jan 01 '12 at 17:40
  • @Centurion a TDG may contain all the SQL queries related to the table: inserts, updates, selects (persistence logic). It should not contain code processing the query results (business logic). Put that either in a [Domain Model](http://martinfowler.com/eaaCatalog/domainModel.html) or a [Table Module](http://martinfowler.com/eaaCatalog/tableModule.html) – Gordon Jan 01 '12 at 18:16
  • Got the idea :) but I have one more question. One table module class maps to one table, so IMHO such table module class might be considered as a model (when talking in MVC context)? What about domain model, what should be considered a model then? A group of classes that are used for concrete controller? – Centurion Jan 01 '12 at 18:58
  • Also, I just started to think about the third pattern - Data mapper. IMHO this pattern is very similar to TDG because both ways, SQL stuff resides in datasource class (in TDG "Person Gateway", in DM "Person Mapper") and business logic in model class ("Person"). How do you see the difference? – Centurion Jan 01 '12 at 19:11
  • @Centurion sorry, but explaining the various architectural patterns is beyond scope for a comment. It would take way too many words. In a nutshell, Model is everything that isnt View or Controller. Domain Model and DB Access are just layers inside the Model. Data Mapper uses a TDG but is not a TDG. DataMappers map row data to domain objects. Check out some of my previous answers on this topic: http://stackoverflow.com/search?q=data+mapper+user%3A208809 – Gordon Jan 01 '12 at 20:57