ActiveRecord is fine. It is a tool that does just what it’s designed to do. What sucks is when developers try to make it do other things than what it’s intended to do.
I worked for Zend, managing the Zend Framework project through its 1.0 release. I also completed the implementation and documentation of
Zend_Db and its related components. To set the record straight, Zend_Db does not implement the
ActiveRecord pattern. It implements the
Table Data Gateway and
Row Data Gateway patterns, which taken together offer similar value as the ActiveRecord pattern.
I totally agree with Mike Seth that MVC should not be taken as “ActiveRecord-View-Controller.” I tried to make this point in documentation, screencasts, conference presentations, and in many mailing list messages, but I met with little success.
Unfortunately, the Ruby on Rails drumbeat that
Models are simply database table wrappers has established momentum. The term “Model” has (incorrectly) become synonymous in many developers’ minds with “ActiveRecord.” Since Models by this definition are tied to database access and largely implementing various query techniques, Ruby on Rails development forces you to write a large amount of code in the controller classes that should properly be written in Model classes.
This has a few consequences. Unit-testing controller classes becomes very complex, since that’s where the majority of your application code resides. To test a controller class you need to mock HTTP requests, and sift through HTML output. This is fine, but it results in more work since testing the controller class is so important and complex. If the application code were separated into a true Model, then unit-testing the controller would simply be testing whether the HTTP request had been communicated to the Model correctly. Testing the behavior of the Model would be much more straightforward unit-testing of a class API in isolation, requiring no mock HTTP requests or scraping HTML output.
Also, unit-testing Rails-style Model classes is difficult, since the Model is coupled with the database. We start to see unfortunate things like
database fixtures as being necessary before you can execute the simplest tests against your Model class. This makes testing Models time-consuming, error-prone, and run slowly.
If developers were to separate Models and Controllers properly, and separate data access components from Models, unit-testing all of these classes could be done more simply, and with greater isolation from other classes. This makes it easier to diagnose defects, when they occur. Isn’t this the point of unit tests?
A Model is a class that provides a logical component of your application domain. Models are products of OO design, which is a development activity I see get very little attention in the developer blogosphere or the developer tools market. Developers seem more enchanted by evangelizing their favorite code editor or debugger, or by squeezing more performance out of their database, than by mental analysis to make sure their OO architecture is modeling its application requirements well.
A single Model class may be backed by a database table, or multiple database tables, or perhaps even no database tables. Data persistence should be an internal implementation detail within a Model; the external API of the Model class should reflect its logical OO requirements, not the physical database structure.
(update) What I often tell people is that the relationship between a Model and an ORM class should be “HAS-A” rather than “IS-A.” The latter is the assumption of Rails and other frameworks who are enticed by ActiveRecord. If the Model uses ORM objects instead of inheriting from ORM classes, then you can design the Model to contain all data and code for the domain it’s supposed to model — even if it takes multiple database tables to represent it.
Many developers have complained that Zend Framework provides no base Model class. Of course it doesn’t provide a base Model class! That’s your job. This complaint is like saying that Microsoft Word sucks because it doesn’t provide finished documents for you.
So I wouldn’t say ActiveRecord sucks. I would say that people are expecting ActiveRecord to magically solve their OO design for them, in a false quest to avoid doing the design themselves.