| « Learning Zend Framework: A Case Study | In Defense of Development Practices » |
Were I writing this as an article for a newspaper, the subhead would be “Design Patterns Don’t Cause Application Slowness.” The point of this piece isn’t to defend Active Record per se; it’s to discuss the fact that design patterns aren’t to blame for your application’s problems, and more to the point, design patterns aren’t the problem.
This discussion stems from a discussion with a friend of mine who swore up and down that Active Record was a terrible design pattern that was inefficient, poorly designed, and ill-suited for use by developers. As a PHP developer, it’s easy to embrace this call, especially since it’s always fun to trash Ruby on Rails folks; however, I’m not willing to take the position that design patterns are the cause of performance problems.
Design patterns are examples of common problems and their solutions. Active Record, along with Decorator, Factory, Flyweight, etc. are all examples of common problems with code-based solutions. That’s it! Design patterns try, in a code-based example, to solve a common problem that developers need to solve.
Some patterns are better at solving certain problems than others; there are varying kinds of ways to interact with a database besides the Class-Table Instance-Row behavior of Active Record; implementing one design pattern over another is a decision of personal choice and need. But design patterns themselves do not cause performance problems.
What causes performance problems? Databases. Hardware bottlenecks. The specific implementation of the design pattern. There are all kinds of factors that relate to creating performance problems or scalability issues that have nothing to do with the design pattern itself. And while it’s easy to look at certain patterns and proclaim that they are diametrically opposed to good performant software, it’s much harder to realize that every pattern has its place, even in some of the best software in the world.
Design patterns aren’t about picking an efficient implementation and running with it. They’re about solving programming problems. Blaming design patterns for performance issues is ultimately blaming the wrong culprit. When we use patterns for their intent – to solve difficult, common problems – they are extremely helpful, regardless of the performance implications. Active Record, like every other pattern, isn’t a bad design pattern when it solves our problem – even if we have to rethink performance in the process.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 3/16/2010 at 9:00 am
stefan (@skoop) wrote at 3/16/2010 9:20 am:
Yes. The design pattern is never the problem, it’s the developer that tries to solve a problem with the wrong design pattern that’s to blame. So instead of saying Active Record is wrong, one should say “the use of Active Record in this situation is wrong”.
Joe LeBlanc (@jlleblanc) wrote at 3/16/2010 9:52 am:
Agreed, most places where I see Active Record being used in Joomla involve inserts or updates, which aren’t going to get much faster if you try to write them by hand.
Matthew Turland (@elazar) wrote at 3/16/2010 10:00 am:
I agree as well. Don’t blame the saw if you’re trying to use it to drive a nail. This isn’t the first time the topic has been broached on the interwebs, though. ;) http://karwin.blogspot.com/2008/05/activerecord-does-not-suck.html
Eli White (@EliW) wrote at 3/16/2010 10:12 am:
I’ll echo what others have said. Sure, Active Record by it’s nature entails some ‘slowdowns’. But (and this is the performance guy talking), that isn’t always everything. In the end, it’s choosing the right code for your situation. I’m a pragmatist at heart. If using Active Record helps you develop your particular application, cool. Just don’t get so HOOKED on the concept of Active Record that when/if the times comes to gut it out of your code, you can’t.
In general, I believe that’s the case with most ‘design patterns’. They are great ideas to use from time to time. But the problem often comes that people see they have a hammer, and so use the hammer. And that’s where problems lie.
Brandon Savage (@brandonsavage) wrote at 3/16/2010 10:42 am:
I had meant to include that link in the entry; I guess that’s what happens when you write a blog post on one machine and publish on another. At any rate, thanks for pointing it out; the more people writing on this topic, the better!
PHP and MySQL wrote at 3/16/2010 10:47 am:
I think in MOST cases “slowness” comes because of bad database schema designs, so don’t blame the DB engines, blame yourself or whoever was the architect of the system (-;
Ivo (@Ijansch) wrote at 3/16/2010 1:23 pm:
It’s not the design pattern that’s the problem, it’s the CHOICE of design pattern. A poorly chosen design pattern can break an application. If you choose ActiveRecord where it’s not a valid solution, it WILL be the problem. Most of the time people complain about a pattern they are not complaining about the pattern per se, but about a particular application’s choice to use said pattern.
Bill Karwin (@billkarwin) wrote at 3/16/2010 2:27 pm:
The phrase “Rapid Application Development” has two meanings:
1. to develop applications rapidly;
2. to develop rapid applications.The value of any ORM solution is to improve the first, at the expense of the second.
bungle wrote at 3/16/2010 5:00 pm:
Only the best abstractions come with few down sides. Unfortunately Active Record isn’t one of them. Peter Norvig has demonstrated that design patterns are a limitations of the actual programming language.
RoR made Active Record popular, but people still feel it’s a wrong solution. The performance is one of the least important down sides of AR.
| « Learning Zend Framework: A Case Study | In Defense of Development Practices » |