DAO vs ORM vs ActiveRecord vs TableGateway vs AHHHH!

Can someone help me clearly understand the differences/relationships between all these? for a while I thought I had a good idea but lately I’m not so sure.


ORM - O/R M - Object/Relational Mapping: A technique/idea used to map objects and thier individual relations to an relational database(mysql, postgresql, mssql, oracle, db2, pretty much any major db today)

DAO - Data Access Object: An object used as a gateway to one row in one table in one database, it only encapsulate that rows fields and no logic - also called Row Data Gateway. (not 100% sure about this one - if this realy is the DAO definition, marcus?)

DataMapper: A layer of software that keeps the Domain Objects(ie: your language level objects such as Person, Group, Membership, Post, etc.) independent of the storage mechanism used for them, and vice versa.

ActiveRecord: Very similair to the DAO/Row Data Gateway but this design also includes logic that operates on the internal values of the row it represents, finder methodss, update methods, domain logic, etc.

TableGateway: Also known as TableDataGateway, one object acts as a gateway to one table in your database. All access to this tables goes through this object.

Hmm. Ok, I think I had most of that right.

Although, I’m still trying to exactly grasp what makes a DataMapper more/different than ORM/ActiveRecord.

Would it be fair to say that ORM/ActiveRecord deal specifically with relational databases but DataMapper could involve something else like flat text?

Often the DataMapper is used by an ORM/AR implementation to map objects into tables.

Hmmm. I understand that statement alone, but combined with your first reply I’m confused - or looking at this the wrong way.

Your first post gave me the impression that ORM/AR is of a finer granularity that a DataMapper - as in perhaps a DataMapper would use one of them.

But now you’re saying that an ORM/AR implementation would used a DataMapper.

Or is is that an ORM/AR implementation inherently use the DataMapper pattern?

Thanks for walking me through my own confusion =/

Well, the O/R Mapping is a technique on how to map objects to tables and vice versa. Active Record is one type of implementation of this tecnique, a relativley simple and straight forward one that maps objects to tables one to one. A DataMapper could be said to be another type of O/R Mapping implementation (not 100% true tho, as the datamapper can be used for other stuff, but for simplicitys sake let’s assume this) that issolates your domain objects(Person, Group) from the database that holds them and vice versa.

I Guess you could say that in Active Record the objects (Person, Group, etc.) knows how to persist themselves while if you use a DataMapper the objects are totaly unaware (if you’ve made a good implemenation, which is kinda tricky and involves major code gymnastics) of the database and have to ask the mapper, “can you save me to the database?”.

I think DAO is a pretty generic term.

Sun defines it as:

And more specifically in their Core J2EE patterns as:

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.

Which could be applied to numerous more specific O/R patterns, IMO.

Hrm, so by that definition DAO would be just an abstraction, like ADOdb?

At least, that’s what I get from it. So yes, an abstraction itself could be applied by more specific patterns.

Well, it’s pretty much in the name “Data Access Object”, you access data thru it :slight_smile:

uhhh… weren’t you the one who just said you thought that DAO was a Row Data Gateway?

Yes, and the row data gateway is exactly that - a way to access the data for one row. I’d say that the term DataAccessObject is way to general tho, as it can basicly be anything at all. But if we’re talking ORM/Mappers/AR/etc then yes, DAO == RDG if you generalize a bit.

Yes if we use Sun’s definition, all Row Data Gateways are DAOs, but the opposite is not true. It is quite illogical to say so. Many other patterns are also DAOs.

Logically, all Row Data Gateways are DAOs. Some DAOs are Row Data Gateways. Therefore, not all DAOs are Row Data Gateways.

Then care to explain Sun’s CatalogDAO example, which is not a row gateway or even a table gateway in a strict sense (it encapsulates 3 databases tables related to the application’s “catalog”).

Yes I agree, but this guy here(beetle) hardly knows the differnece between dm, tdg, dao, ar and o/r m(nothing wrong with not knowing the difference) as far as I can see so instead of argueing over nitty gritty details I generalized a bit, geez… take it easy.

Ok, how about this then:
DAO instanceof RDG = false
RDG instanceof DAO = true

Happy? It’s such a little detail realy, why do you even bother jump on me for that ?


And since when was Sun’s PoV universal law?[/edit]

But I’m after the details so I can know the difference :frowning:

When we’re talking ORM there’s basicly no difference. You can say that a DAO is an object that access some type of data(often external) for you, and a Row Data Gateway is an Data Access Object that specificly access a table row. Which means that a DAO is not an RDG, but an RDG is a type of DAO.

I’m not jumping on you. You said you weren’t sure of the definition of DAO, so I posted Sun’s definition, which you then try to twist exactly as being the same as your own definition. If you have your own definition, then that is fine and one thing, but trying to twist other views into your own mold is not only ludicrous, but also an archaic mindset.

Also, again I’m not jumping you. It’s a discussion forum, and above all the understanding of the OP is most important. Continually trying to assert misleading statements like “a dao is just a row data gateway” does the OP no good in understanding what they are trying to understand.

So if it hurts your feelings for me to point out incorrect statements, well I’m sorry but don’t take things so personally (or don’t be so wrong :wink: ).

Where did I try to twists suns definition? :slight_smile: I just said that “since when is Sun’s PoV universal law?”

Ok, here’s what I’ve taken from this thread so far.

Very generic term that doesn’t infer any specific implementation. Simply what it says on the tin, an object that accesses data.

The mapping of object data to relational database data. The database data could be a single row, a single table, multiple rows in a single table, multiple rows in multiple tables, or any other such relationship.

Similar to ORM, but doesn’t necessarily infer that relational data is being mapped.

Active Record
ORM that represents a single row in a single table.

TableGateway or TableDataGateway
DAO for a single table

RowGateway or RowDataGateway
DAO for a single row

Let me know if I’ve got it right, or am at least hitting close to the mark.