[Catalyst] Using model layers between Catalyst and DBIC

Jason Galea lists at eightdegrees.com.au
Mon Jan 2 03:36:32 GMT 2012


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 retu=
rn
> the new user object or throw an exception on failure.   What probably mak=
es
> 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?   A=
ny
> 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 consistent
> API is provided -- making it easy to hook it into Catalyst for things like
> 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/6d324=
826/attachment.htm


More information about the Catalyst mailing list