Bill, I've done this a lot in the past, as well as a few other approaches. In the end I've come to the conclusion that although off the top it seems like a nice interface, it doesn't grow old well and can be confusing to people trying to read your code. I now tend to think that a consuming class should only build its objects when and if it needs some way to influence how they are built. Otherwise over the long term you end up with a confusing interface with a lot of stuff completely unrelated to the actual functioning of the class. And it harder to test correctly.
I'm not sure what a better approach could be, but lately I've been taking the idea of having dedicated builder classes. I know that sounds heavy handed, but at least it has the upside that my concerns are more carefully separated. Good luck and very interested where this thread goes! John >________________________________ > From: Bill Moseley <[email protected]> >To: [email protected] >Sent: Tuesday, September 4, 2012 2:07 PM >Subject: Should I coerce a DBIC schema from HashRef? > >Looking for a bit of guidance on design. > >I have a growing number of classes that require a DBIx::Class "schema" >attribute. These classe are used as Models in Catalyst (where they get the >Catalyst app's schema passed in to the constructor), but they are also used >in command line tools and cron jobs. > >It makes sense to coerce a URI object from a string, and even a DateTime >from an integer or a string -- and MooseX::Types::DateTime and >MooseX::Types::URI do that. But MooseX::Types::DBIx::Class does not coerce >a schema object. > >Is there any reason I would not want to coerce a schema from a hashref? > >I guess another option would be a role that includes individual attributes >for schema class, dsn, user, passwords, and \%options and use a >_build_schema method. This is an approach I've used in the past. > >BTW, I used DBIC as a familiar example, but many of my classes need more >than just a DBIC schema -- they often need a logger, and a few other >classes so this question isn't limited to building a schema object. > >-- >Bill Moseley >[email protected] > > >
