[ACCEPTED]-What is the difference between the Data Mapper, Table Data Gateway (Gateway), Data Access Object (DAO) and Repository patterns?-table-data-gateway

Your example terms; DataMapper, DAO, DataTableGateway 14 and Repository, all have a similar purpose 13 (when I use one, I expect to get back a 12 Customer object), but different intent/meaning 11 and resulting implementation.

A Repository "acts like a collection, except with more elaborate querying capability" [Evans, Domain Driven Design] and 10 may be considered as an "objects in memory facade" (Repository discussion)

A DataMapper "moves data between objects and a database while keeping them independent of each other and the mapper itself" (Fowler, PoEAA, Mapper)

A TableDataGateway is "a Gateway (object that encapsulates access to an external system or resource) to a database table. One instance handles all the rows in the table" (Fowler, PoEAA, TableDataGateway)

A 9 DAO "separates a data resource's client interface from its data access mechanisms / adapts a specific data resource's access API to a generic client interface" allowing "data access mechanisms to change independently of the code that uses the data" (Sun Blueprints)

Repository seems very generic, exposing 8 no notion of database interaction. A DAO 7 provides an interface enabling different 6 underlying database implementations to be 5 used. A TableDataGateway is specifically 4 a thin wrapper around a single table. A 3 DataMapper acts as an intermediary enabling 2 the Model object to evolve independently 1 of the database representation (over time).

There is a tendency in software design world 17 (at least, I feel so) to invent new names 16 for well-known old things and patterns. And 15 when we have a new paradigm (which perhaps 14 slightly differs from already existing things), it 13 usually comes with a whole set of new names 12 for each tier. So "Business Logic" becomes 11 "Services Layer" just because we say we 10 do SOA, and DAO becomes Repository just 9 because we say we do DDD (and each of those 8 isn't actually something new and unique 7 at all, but again: new names for already 6 known concepts gathered in the same book). So 5 I am not saying that all these modern paradigms 4 and acronyms mean EXACTLY the same thing, but 3 you really shouldn't be too paranoid about 2 it. Mostly these are the same patterns, just 1 from different families.

Data Mapper vs Table Data Gateway To make a long story short:

You have a good point. Pick the one you 32 are most familiar with. I like to point 31 out few things that may help clarify.

The 30 Table Data Gateway is used mainly for a 29 single table or view. It contains all the 28 selects, inserts, updates, and deletes. So 27 Customer is a table or a view in your case. So, one 26 instance of a table data gateway object 25 handles all the rows in the table. Usually 24 this is related to one object per database 23 table.

While Data Mapper is more independent 22 of any domain logic and is less coupled 21 (although I believe either there is coupling 20 or not coupling). It is merely a intermediary 19 layer to transfer the data between objects 18 and a database while keeping them independent 17 of each other and the mapper itself.

So, typically 16 in a mapper, you see methods like insert, update, delete 15 and in table data gateway you will find 14 getcustomerbyId, getcustomerbyName, etc.

Data 13 transfer object differs from the above two 12 patterns, mainly because it is a distribution 11 pattern and not a data source pattern as 10 above two patterns. Use it mainly when you 9 are working with remote interface and need 8 to make your calls less chatty as each call 7 can get expensive. So usually design an 6 DTO which can be serialized over wire that 5 can carry all the data back to the server 4 for applying further business rules or processing.

I 3 am not well versed in repository pattern 2 as I did not get a chance to use till now 1 but will be looking at others answers.

Below is just my understanding.

TableGateWay/RowDataGateWay: In this 25 context, Gateway is referring a specific 24 implementation that has each "domain object" mapping 23 to each "domain object gateway". For example, if 22 we have Person, then we will have a PersonGateway to store 21 the domain object Person to database. If 20 we have Person, Employee, Customer, etc, we 19 will have PersonGateway, EmployeeGateway, and 18 CustomerGateway. Each gateway will have 17 specific CRUD function for that object and 16 it has nothing to do with other gateway. There 15 is no reusable code/module here. The gateway 14 can be further divided into RowDataGateway 13 or TableGateway, depends if you pass an 12 "id" or an "object". Gateway is usually 11 compared with Active record. It ties your 10 domain model to database schema.

Repository/DataMapper/DAO: They are 9 the same thing. They all refer to the Persistence 8 layer that transfer database entities to 7 domain model. Unlike gateway, the Repository/DataMapper/DAO 6 hide the implementation. You don't know 5 if there is a PersonGateway behind Person. It 4 may, or it may not, you don't care. All 3 you know is it must have CRUD operations 2 supported for each domain object. It decouple 1 the data source and domain model.