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.

A Growing Dislike for SQL-OOP Mappers 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That's one of the main problems with those two modules, they force you into an is-a relationship. The right way to do it, IMO, is a has-a relationship. Your OO module, which provides your public API, should _have_ some sort of SQL-ish module to do the work.

    Now that mapper can create whatever methods it wants, and you don't care. I don't think this has much to do with mappers in general as much as the ones you've chosen, which force you to subclass them.
    • I'm confused by this statement. Class::DBI doesn't force you into an is-a model at all. A Class::DBI class merely represents a database table. It can quite happily be the class that your nice pure OO model class 'has'. Class::DBI provides your "sort of SQL-ish module to do the work". It's not trying to be part of some nice OO system.

      Tony

      • What you say is true. It'd probably be good if the docs recommended this sort of usage, for exactly the reasons that the original journal entry mentioned.

        But in that case most of your C::DBI classes would _just_ be the declarations, which isn't how I've ever seen anyone use it.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.