Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Whip Me, Beat Me, Make Me Use ORMs

by Ovid (Cardinal)
on Jun 29, 2007 at 09:31 UTC ( #624068=perlmeditation: print w/replies, xml ) Need Help??

It's phenomenally easy to abuse object relational mappers (ORMs). I see all sorts of silly things going on with them and I'm cocky enough to think that I can avoid the worst of problems with them, but I'm humble enough (ha!) to know that others can give me great suggestions.

I want to do a write-up for my O'Reilly blog about how to minimize problems with ORMs. There are plenty of articles about which ORM to use or whether you should use them, but I want to focus on how to use them properly if you must. The important thing is to actually understand object-oriented programming and how an ORM can hinder this when abused. Thus, the goal is primarily to not treat the ORM classes as your actual object layer, but to have them hidden by your object layer (or model, if you prefer).

What techniques would you have for others to adopt or avoid when using ORMs? If fact, when would you choose to use or not use an ORM? (Note, I'm assuming you think there might be some proper role for an ORM. I've read plenty of "never" arguments and that's not what I'm looking for here.)


New address of my CGI Course.

Replies are listed 'Best First'.
Re: Whip Me, Beat Me, Make Me Use ORMs
by merlyn (Sage) on Jun 29, 2007 at 13:28 UTC
    The biggest problem with ORMs is the same problem I see with OO frameworks that generate public accessors for member variables.

    Accessors for member variables turn objects into glorified structs. When you design an object's interface, it really should be in terms of messages, not in terms of what guts the object contains.

    SImilarly, ORMs map each column into the interface, instead of mapping the interface from the use cases. Surely, you could create "actual" objects that encapsulate that, but I don't see that happening very often (even in my own code).

    What happens when the DBA decides that street address should actually be two fields: street number plus street name? We now have to ripple that through all the code, because all the code was talking directly to the street address text field before. Sure, we can do some wrappers and things, but a proper OO design would have minimized the locality of that knowledge. ORMs don't encourage that design.

      I'm actually working on actual objects which encapsulate that, but I made the mistake of inheriting instead of delegating, thus exposing too much. I have a robust enough test suite that the refactoring should be easy, but I'm kicking myself for being so stupid.

      Of course, if one has a poorly designed database, making this distinction is even more important.


      New address of my CGI Course.

Re: Whip Me, Beat Me, Make Me Use ORMs
by lima1 (Curate) on Jun 29, 2007 at 13:32 UTC
    If fact, when would you choose to use or not use an ORM?

    The obvious: I would think twice if I should use an ORM when performance is REALLY critical. Maybe some tutorials on how to profile queries and improve the performance would be nice. In my (humble) experience, this isn't that trivial...

      A decently fast ORM like Rose::DB::Object probably wouldn't be noticable for most of the accesses. For the critical ones, you could push the queries down directly as handwritten SQL using the same database handle, so RDBO gets out of the way when you need it (as do other ORMs).

      merlyn is right. Rose is wicked fast. It's fast enough that you're unlikely to notice too much of a difference and it's easy to fine-tune, if needed. The wins with Rose (and its clean design), easily outweigh the losses.

      You can see the benchmarks for yourself.


      New address of my CGI Course.

        When you work with many tables and gigabytes of data, you have to fine-tune many queries. The last time I had these problems, this tuning was not that easy because an ORM is kind of a blackbox - RDO probably less than others. I ended up with ugly code that was not more maintainable than plain DBI code. Well, probably I am someone who does silly things with ORMs ;)

        But I really like RDO, so I'd interested in reading more about things you should consider (probably starting with the db schema) when you go beyond little webapp databases ;)

Re: Whip Me, Beat Me, Make Me Use ORMs
by aufflick (Deacon) on Jul 02, 2007 at 02:14 UTC
    I think the key is not to pretend that an ORM makes the RDBMS go away. If you really want truly seamless object storage, use an OODBMS. If you want to use an RDBMS with OO code then by all means use an ORM to eliminate a good portion of code in regular cases, but make sure your ORM also makes it easy (and clean) for you to use manual queries for object retrieval or plain data (non-object) retrieval.

    On a similar note, if you're storing serious amounts of data you can't (unfortunately) ignore the fact that relational data modeling and functional object modelling are unfortunately not the same. Your database model may not exactly match your object model. Here you again need a flexible ORM, you need to design your object and relational model side by side and be willing to make compromises in both where it makes sense. Lazy object population can also be your friend here when you have particularly costly database retrieval.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://624068]
Approved by Corion
Front-paged by Old_Gray_Bear
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2018-03-18 02:57 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (228 votes). Check out past polls.