What design pattern is PEAR DB_DataObject implementing?

Question

DB_DataObject does not appear to be ActiveRecord because you do not necessarily store business logic in the "table" classes. It seems more like Table Data Gateway or Row Data Gateway, but I really cannot tell. What I need is good ORM layer that we can use with DataMapper and a DomainModel. Any ideas?

Answer 1

Follow this link to read what DB_DO is. In a nutshell, it doesn't implement a specific pattern, it just aims to provide a common interface. The idea is to not rebuild the same basic code in each project.

As for an ORM, I'd recommend Doctrine. It implements ActiveRecord.

Answer 2

I have looked at Doctrine before and it looks interesting. However, by ActiveRecord, I assume you mean that you store business logic in the data access classes themselves? We are specifically looking for something that is not ActiveRecord, in that we would prefer a thin layer of data access that has an OO API, but does not contain any business logic. That all goes into our DomainModel instead (thus the preference for DataMapper). Maybe what I want is just PDO?

Answer 3

It sounds like what you're looking for is something like IBatis for PHP. Sadly, this doesn't yet exist. I've actually written some custom DataMapper stuff based on PDO for the current application I'm working on to achieve a persistence ignorant domain layer. It's definitely more work to develop and maintain though, so I would suggest if at all possible, go with an existing data layer implementation like Doctrine for most of your needs.