fREWdiculous!
26 Aug
At work I tend to play an…Evangelical role? I tend to experiment with various technologies, get sold on them, and then sell them to coworkers. Examples: Apache, DBIx::Class, CGIApp, and lately Catalyst. So I typically find various ways that the new tool helps make my job easier and tell people about that. After they believe me, I then educate them about various nuances and whatnot of the tool. Eventually this will happen with git, when it doesn’t suck so much with Windows.
So recently one of my coworkers asked me why he should use an ORM. I had thought I’d mostly fought that battle, but he wasn’t sold (he is now by far
). Anyway, here is my answer, open to the world.
In general this isn’t a huge benefit. SQL is pretty simple and remembering it’s syntax isn’t so bad. But when you want to do something in like paging in SQL Server is when an ORM really starts to shine. In general the ORM makes tasks that you want to do with SQL all the time nice and simple. For example, since we use Ext at work for most grids, users expect to be able to sort by all columns, have pagination, etc. That’s entirely abstracted away. I rarely think about those pedestrian things now
This is where a good ORM really shines. Instead of trying to remember seemingly transient relationships, like how the Shop table joins with the Orders table, we can document that by writing code using our ORM. After that the relationship is there forever. It’s an entirely new level of code reuse, if you are used to just vanilla SQL, even if you are reusing it with functions.
This is actually a lot more subtle in my mind. When I first started using a ORM for real (DBIx::Class) I kept looking for DBIC ways to do various things. Typically the answer was: “override insert” or “override update.” As a noob this can be pretty intimidating, but it really gives great amounts of flexibility. At some point I’ll do a post on OOP revelations I’ve had (interestingly, mostly I get those from hacking on the code of my ORM of choice
,) but for now I’ll just leave it at that.
What are the reasons that you use an ORM?
update: as Stevan notes, I really shouldn’t say all in the final bullet point above. It’s more subtle than that. When I say OOP I don’t actually mean the classes that the ORM represents inherit from each other. I just meant that if I want to do some extra stuff for one class when I store/retrieve it I can localize those changes.
4 Responses for "Why should I use an ORM?"
In the case of my ORM ORLite, it’s that I can have a whole class tree of useful code with literally one line declaration
Saying that an ORM gives you “all” the features of OOP is actually wrong. In fact the three main features of OOP are either broken or stilted in ORMS.
First you can’t easily do inheritance, yes there are patterns you can follow to fake inheritance, but they all end in compromise and tears.
Second, there is no real polymorphism available. You cannot treat a Employee the same as a Person because the Employee.id will not be in the Person table. Again, you can fake some of this, but thats not real polymorphism then.
Lastly, because your object data is stored in tuples in a RDB you have no real encapsulation. Sure the objects created by your ORM might be encapsulated but a simple errant SQL statement could bring your whole house of cards crashing down.
In the end a RDB is just a tuple store with implied relationships and Objects are a graph with explicit relationships, they are simply not compatible.
Personally I try to use object graph engines like KiokuDB for my objects and $RDBMS for my tabular data as often as possible.
@Stevan, you’re right. I stand corrected. I changed the post a little to reflect that.
“ORM’s let you forget SQL”
I’m gonna take exception to this too. Except in very rare cases the *best* ORMs are the ones that don’t let you forget SQL but that instead normalize SQL so you can forget the crappy implementation your RDBMS vendor provides. This is certainly true of Fey and DBIx::Class. Talking with Matt Trout at one point I pointed he suggested that until you saw the SQL through the DBIC you didn’t really get it, and once I started looking at it that way my DBIC usage became *much* more powerful.
I agree with Stevan that if you really want an OO Paradigm that lets you totally forget SQL a graph store like KiokuDB is the way to go. If you have highly related aggregate data then SQL is the right answer and DBIx::Class is my favorite Perl ORM.
Leave a reply