Robert C. Martin (Uncle Bob) wrote an interesting article about Active Record and objects. I do admit that he is partially right but I don't agree with him fully.
Martin Fowler's definition of Active Record is
An object that wraps a record in a database table or view, encapsulates the database access, and adds domain logic on that data.
Uncle Bob wrote
The problem is that Active Records are data structures. Putting business rule methods in them doesn’t turn them into true objects. In the end, the algorithms that employ Active Records are vulnerable to changes in schema, and changes in type. They are not immune to changes in type, the way algorithms that use objects are.
The fact that Active Record is based on database structures does not make it any less object-oriented. Active Record does not even try to solve the impedance mismatch between databases and objects. A full-blown ORM-tool should be able to solve the discrepancy. I don't see Active Record as an object-relational mapper at all. Ok, you can always say it's 1:1 mapper and it's hard to argue against that.
It has “hidden” data, and exposed behavior. I put the word “hidden” in quotes because the data is, in fact, not hidden. Almost all ActiveRecord derivatives export the database columns through accessors and mutators. Indeed, the Active Record is meant to be used like a data structure.
Active Record does not imply that data is exposed directly and this is the first time I've heard that AR is meant to be used like a data structure. Most of the AR-frameworks just are a bit liberal on data visibility but so are also many ORM-tools.
Applications should be designed and structured around objects, not data structures. Those objects should expose business behaviors, and hide any vestige of the database. The fact that we have Employee tables in the database, does not mean that we must have Employee classes in the application proper. We may have Active Records that hold Employee rows in the database interface layer, but by the time that information gets to the application, it may be in very different kinds of objects.
Active Record couples the object design to the database design. I don't see it as a problem. It's a design choice. In many cases it's totally acceptable approach. But if the business logic is complex or you want to use for example inheritance, the design gets messy quite soon. That will lead you to for example Data Mappers and full-blown ORM-tools.
