Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Are Object-Relational Mappers Worth It? 1 Comment More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Because writing code that generates code sucks. A good ORM will give you an API to compose queries. It’s the difference between eval and using closures, roughly.

    I use DBIx::Simple and SQL::Interp to make SQL generation suck less, but it fundamentally can’t be made to not suck at all. And you still need to some sort of OOD for the layer that encapsulates your model, unless you’re content with a random collection of 300 SQL query wrapper methods in a single class.

    There are two major wins I see in using a good ORM: being able to represent queries as first-class language entities that can be manipulated (and thus assembled piecemeal by different parts of the code, and munging the data returned from the database to turn columns retrieved via joins into nested data structures. These two concerns give rise to most of the monkey code I end up writing when I go the hand-written SQL generation route. DBIx::Class happens to get closer to the ideal than any other ORM I’ve seen.

    the ORM frequently wants us to assemble a bunch of objects and then extract the data we need – a useless and expensive intermediate step.

    You know about HashRefInflator [cpan.org], right?

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.