Hello perl-bikkhus!

I've been working on a photographer's application suite for several months, in Perl. It's object model contains about 20 business objects in photographer-speak: Client, Shoot, Image, and so on. And about 15 many-many relationships between these objects, which a user of the object model API never has to deal with directly.

It's implemented using Class::DBI against a MySQL backend. If you've never used Class::DBI and would like to be able to dash off a complex data model in a few hours, look into it. And then look into its helpers, Class::Accessor and friends. Then look into your alternatives, which I encourage fellow monks to suggest in comments below.

Now, after being quite pleased with how easy the modeling was, even the 15 many-manys, letting me get on to the 'more important' business of application coding (it has a CGI and command-line interface, GUI coming soon(TM)). All was well until... bumbumbum.... requirements change.

The app system must now be able to dump its records as XML, as well as read records. Ideally, the XML records would be fairly human-readable, follow the same object model previously developed for the Perl API, and be potentially recoverable or exportable to other apps as painlessly as possible. Eventually, database replication may occur over an XML pipeline, so the XML schema-space ends up covering the entire Perl API.

In other words, like so many Perl data objects these days, I need to be able to serialize the object's state into XML, and move between different datastores. Many times, I will not have access to a DBI (or more specifically, Class::DBI) type datastore, and will operate in XML-only mode.

Unfortunately, one place where Class::DBI doesn't shine so well is operating in "in-core-only" mode. In fact, there's no such thing :-). AFAIK, You can't (meaningfully) work with Class::DBI subclasses without a real, working database with your particular schema.

Ok, you can do some wizardry - maybe even edit Class::DBI to you liking - but that seemed grueseome. And my new req's do allow me to have Class::DBI initially disabled, and then turn it on later. So I didn't have to implement a "turn-off" feature, just a more careful object loader ("don't turn Class::DBI on until I say to").

I've started writing a "Pure Class" that follows the object model already established, and I have abstracted out the persistence engine (CDBI or XML) as an optional has-a instance attribute. So, a FooApp::Shoot has-a FooApp::CDBI::Shoot, and so on. Sounds easy, right....

Traps I've hit so far, and feel free to add:

You see where I'm going. Mind you, I'm still getting a lot of mileage out of Class::DBI as the worlds niftiest SQL generator, but whew, this looks hard. And perhaps a monk has been down this road before....

In reply to many-many relations in object modeling by other90percent

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.