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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The amount of repetitive, error-prone code saved by an ORM is well worth the cognitive and performance overhead, IME. But like any abstraction, ORMs have their limits, in both directions. Developers have to know when to put down the hammer and pick up a different tool because not everything is a nail. In the case of ORMs, that fact that everything looks so regular and friendly lulls developers into forgetting the real (and usually ugly) database lurking under the covers.

    Experience teaches you when "back-solving" from custom-written SQL into the ORM equivalent is not worthwhile, when stored procedures are a better choice than issuing client-side queries, when you must bite the bullet and use your db vendor's crazy proprietary mechanism for a certain task, when you shouldn't use a db at all, and so on. But none of these things is an argument against ORMs in general. The only cure for their over-use in inappropriate situations is education and experience.

    Your example is a good one: most of us have learned the hard way the pitfalls of putting unrelated logic in templates. Today, Mason and other templating systems still allow this, but experienced developers have learned the limits of what's wise. The same could be said of Perl itself, where nearly anything is possible, but not everything is advisable.