On Thu, Jan 21, 2010 at 6:37 PM, Jeff Albert wrote:

or should I create a separate �application object� model which brokers
requests from the Controllers and uses the DBIC model to implement them if
they fit the application�s logic? I�ve looked far and wide to try to better
understand how this pattern should work, since I can see the benefit of the
better code reuse and easier maintenance it would entail; I just need some
advice to get me started. Suggestions?

Jeff Albert


I personally try not to put logic in the DBIC schema classes, because I use
Moose features, such as roles, extensively. Hence I end up having many Moose
classes (ie Employee.pm) that look just like their underneath DBIC schema
class (ie Schema/Result/Employee.pm). The Moose class will implement all
complex calculations and validations, and proxy for the bare basic DBIC one.
The decoupling is certainly beneficial, but the attribute redundancy bugs me

So ideally I would like to have DB entities represented by a single Moose
class, rather than in 2 or more places. For that there's KiokuDB and
MooseX::NonMoose-- the latter should allow a moose class to inherit from a
DBIC class. Haven't tried neither, though.

- rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100121/68bae321/attachment.htm

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 7 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJan 21, '10 at 5:37p
activeJan 22, '10 at 8:31p



site design / logo © 2022 Grokbase