by 
In the last blog post, I provided a comprehensive example of using ActiveJDBC ORM. As I stated there, ActiveJDBC is an implementation of the active record pattern. And it inspired by ActiveRecord ORM from Ruby on Rails. In this article, I share my thoughts about the active record pattern.
Background
Active record pattern introduced the first time by Martin Fowler in Patterns of Enterprise Application Architecture book, 2002. He describes Active Record as:
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
Later he adds that (source),
An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.
This means that the object represents the database row also consists of logic on how to access to the row, let say CRUD operations, as well as all the business logic. This exactly is the opposite of service layer design that’s very common in Spring combined with Hibernate ORM.
Active record advantages
The main advantage of the active record is its easiness to quickly implement a throwaway prototype. It’s a good choice for Rapid Application Development (RAD). However, this is less apparent nowadays that many enterprise-level frameworks allow wiring everything with little configurations, such as Spring Data JPA.
In addition to that active record does not have the Anemic Domain Model issue which is common in Service Oriented Architecture (SOA). Or at least the issue is less visible since there is no database model is exposed.
Active record disadvantages
Now that I have already discussed about the advantages of the active record, let’s talk about the issues that this pattern poses.
The first and foremost problem of the active record is breaking of the single responsibility rule. A single active record class contains low-level database interaction logic, and business logic, as well as validation logic. This is obviously is not a big deal in small scale applications but it is nearly impossible to maintain in enterprise level applications where multiple people working on the same project.
Due to that, sooner or later all logic will tangle together and the code became spaghetti.
The second and third issues are scalability and maintainability. These are inevitably are the side effect of breaking single responsibility principle which I have touched down in the previous paragraph.
The other issue of the active record is testability. It’s very difficult to do testing at unit level for Active record because it requires the database availability. Additionally, due to encapsulation some of the methods are private and this further makes testing difficult.
Conclusion
In this article, I briefly touched down about active record pattern with its pros and cons. It is pretty clear by now that the active record is an anti-pattern. Developers should avoid using it even though it brings speed which is good for RAD and prototyping. As long as the code does not have much of business logic there is nothing to worry about. However, maintaining a complex codebase uses the active record soon or later becomes unsustainable.
Let’s not forget that the agility that the active record provides, later on comes down as the technical debt. Hence, personally, I rather spend more time initially than patching the system every other day and dealing with too many bugs and regression.
