[Catalyst] Using model layers between Catalyst and DBIC

[Jason Galea]

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.

J

On Mon, Jan 2, 2012 at 1:36 PM, Jason Galea <lists at eightdegrees.com.au>wrot=
e:

> 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
> 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
> delegation.
>
> 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..
>
> cheers,
>
> J
>
>
>
>
>>
>> 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=
urn
>> the new user object or throw an exception on failure.   What probably ma=
kes
>> 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?   =
Any
>> 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=
ent
>> API is provided -- making it easy to hook it into Catalyst for things li=
ke
>> 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:
>> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120102/011e2=
deb/attachment.htm