in reply to Re: Design Question - I've gone object mad!
in thread Design Question - I've gone object mad!

I thought this all felt a bit like "surely someone's done this before!" :)

Tho I feel any use of DBIx::Class would exist even under this level of interface - I nearly want html/TT coders to be able to call my methods, but certainly don't want them this close to the inner-workings of my models.

We're already heavily using MySQL, all old legacy code that's 10 years old, with no objects in sight! This is all new code I'm writing to refactor the old scripts.

  • Comment on Re^2: Design Question - I've gone object mad!

Replies are listed 'Best First'.
Re^3: Design Question - I've gone object mad!
by Your Mother (Archbishop) on Apr 06, 2011 at 00:11 UTC

    Not only has it been done before, it has been done much better than you will do it. If you were experimenting, I’d say, “Hells yeah, go for it and have fun!” But if this is really for work, “You are making a huge mistake and you are punishing the future developers who will hate you for it if they have any sense at all.”

    DBIx::Class (just for one, and there are other excellent ORMs in Perl) works out of the gate with all the common DBDs, it has oodles of support tools for auto-generation of code, introspection, inflation, versioning, helpers, constrainers, dumping, deployment, etc, and it comes with a community, a stable history, and a test suite that concludes as of this moment with–

    Files=251, Tests=5141, 152 wallclock secs ( 2.20 usr 1.28 sys + 125.6 +3 cusr 13.35 csys = 142.46 CPU) Result: PASS

    If you can conjure 5,000 passing tests for your new code, I withdraw my objection.

      for (1..5000) { is(do("SELECT $_"), $_); }

      Way faster than DBIx::Class's test suite too! ;)

        I was guessing someone would do that. :P

      This is true, tho I would see DBIx::Class being used under my layer I am writing (see my later responses for other examples).

      I'm also very aware that we'll soon move some of our data out of a database and over to some other storage engine, such as Solr.

      If it was purely database modelling, I'd be using DBIx::Class in a shot, but my query is more about a layer above the db, a bit closer to the controller aspect of an MVC design, if you like.

        DBIC does that in several ways at a couple of layers in extensible fashion. It's generally called "fat model(ing)." Your layer in this case would be ResultSets, Inflators/Deflators, and virtual ResultSources.

        This design space is all corner cases and the first time painter is going to start in the middle of the room every time.