[Catalyst] Using model layers between Catalyst and DBIC

[Bill Moseley]

Our apps tend to use the "pattern #2" as simply described at: Catalyst
Models Definitive Guide <http://www.perlmonks.org/?node_id=3D915657> -- that
is, our model is DBIC with business logic added to the resultset classes.
But, much business logic is finding its way into the controllers.   The
apps also tend to grow into monolithic beasts.   And we have the need to
use the "app" for multiple uses -- for example we currently need to add a
custom API for a specific purpose that needs to live in its own Catalyst
app.

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.

Anyone here doing something like this?   As I look into this I'm coming up
with quite a few questions, of course.

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 return
the new user object or throw an exception on failure.   What probably makes
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120102/716fb=
522/attachment.htm