On Thu, Jan 21, 2010 at 6:37 PM, Jeff Albert <[email protected]> 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? > > > Cheers, > > Jeff Albert > > [email protected] > > > > 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 nonetheless. 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
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
