[Catalyst] Re: Using model layers between Catalyst and DBIC

[Bill Moseley]

On Monday, January 2, 2012, Jason Galea wrote:

>
> 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..)
>

Yes, where to draw the line is difficult to know.   I've only had a few
hours to work on this but already I feel like I'm reinventing Catalyst --
mostly because my model layer is pulling in much of the components that my
Catalyst app would normally do -- DBIC, caching, even some concept of the
"current user".   Access control is another topic.



> 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.
>

So you are mirroring DBICs class structure a bit.  I need to consider that
approach more as currently my model layer returns the DBIC row object
directly.  So, I have something like this:

my $user_model =3D Model::User->new;
my $new_user =3D $user->new_user( $user_data );

Not as flexible as your approach but my goal currently is to just abstract
out the ORM so that Model::User can hide the specifics of the database.
Actually, it's not that hard to do directly with DBIC, either.



> 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.
>

Can you show a code example of that?  I'm not sure I'm following why you
use that approach instead of having your layer on top of DBIC do that.



>
> 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..
>

Yes, I'm doing something very similar where validation happens before the
method in the model and on validation errors and exception is thrown (if
you are on the Moose list you may have seen my example).

Thanks for the feedback and the ideas,



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120109/e1372=
5bb/attachment.htm