[Catalyst] Using model layers between Catalyst and DBIC
lists at eightdegrees.com.au
Mon Jan 2 03:48:23 GMT 2012
oh, I've also started playing with Bread::Board and its looking like my
"model" layer consisting of the DBIC Schema and all my "Sets" will be
pulled together into a single Bread::Board container.
On Mon, Jan 2, 2012 at 1:36 PM, Jason Galea <lists at eightdegrees.com.au>wrot=
> Hi Bill,
> On Mon, Jan 2, 2012 at 11:41 AM, Bill Moseley <moseley at hank.org> wrote:
>> So, I'm looking at adding a separate model layer(s) ("pattern #3" in link
>> above), as is commonly suggested. My plan is to have one "distribution"
>> that is our DBIC layer and then use that in a number of separate model
>> layers (split out by functionality). The goal is to allow separate teams
>> to work on different parts of the app, have separate unit tests, and
>> separate release schedules. And to thin out the controllers. Much more
>> manageable and scalable.
> I think I've added another layer but I'm not sure where you draw the
> line.. I have a model layer over DBIC pulling together related result
> classes under a single model class. Then the app? layer uses the model
> layer to get things done. So I'd probably have one "distribution" that is
> our DBIC wrapped in a model layer layer and use that in a number of apps..
> 8) Each app can then be used as the single model in a Catalyst app or
> script or whatever.. (I think I need more names for the parts..)
>> Anyone here doing something like this? As I look into this I'm coming
>> up with quite a few questions, of course.
> I've been trying learn the steps to this little dance for a while now and
> still haven't put anything into production, but for what it's worth, here
> are some of the things I've implemented in my most recent code..
> I have "Sets" in lu of ResultSets and "Models" for Results. Although in
> most instances a Model will actually cover the usage of multiple Results.
> Each Set gets the dbic schema object and knows it's resultset name. Each
> model has a data attribute which contains a dbic row object and "handles"
> any methods I don't need to override via the Moose "handles" attribute
> Set->create($hash) creates the dbic object and stuffs it into a model
> class and returns that.
> Each result class that has a model class overrides it's inflate_result
> method which again stuffs the dbic row object into the model object so
> searches on the related dbic resultsets return my model objects.
> Each model class has a validation class based on.. Validation::Class and
> create & update run their input through that. If there are errors I stuff
> the errors into a very basic exception object and return that. This way I
> can return the same exception object no matter where the error comes from,
> eg a dbic exception..
> So my app can use the Login set to create a login model which has methods
> to set/get email & username, check the password, set a temporary
> password, add to roles, and get roles by name. Beneath that is 3 or 4 DBIC
> result classes which the model class works with via custom methods or
> ok, sorry.. I'll stop there. This has turned into a brain dump and clarity
> has suffered badly.. I hope you got something for your trouble..
>> This is more of a Perl question than a Catalyst one, but one question I
>> have is about data validation. Catalyst provides a nice defined request
>> structure so, for example, I have input data validation managed very
>> consistently (e.g. validation classes can be mapped to Catalyst actions
>> automatically and likewise validation errors can be added to the response
>> in a common way). That makes the controller code simple since when the
>> controller runs it knows if the data it has received is valid or not and
>> the controller does not worry about gathering up error messages.
>> So, I'm wondering how best to do that if I provide a separate model layer
>> that includes data validation. For example, say I have a model for user
>> management which includes a method for creating new users. If I have a
>> model method $users->add_user( \%user_data ) I would tend to have it ret=
>> the new user object or throw an exception on failure. What probably ma=
>> sense is using exception objects and have Catalyst catch those to render
>> the error in an appropriate way. Is this an approach you are using? =
>> other tips on structuring the model layer that works well with both
>> Catalyst and non-Catalyst applications?
>> Looking back, I think my question isn't that much about data validation
>> as is about providing a framework for model creation such that a consist=
>> API is provided -- making it easy to hook it into Catalyst for things li=
>> rendering errors in a consistent way.
>> Thanks for any feedback you can provide,
>> Bill Moseley
>> moseley at hank.org
>> List: Catalyst at lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> Dev site: http://dev.catalyst.perl.org/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst