FAQ
Hi List!
I'm a new-ish Catalyst developer, converted from the ranks of the HTML::Mason faithful, and the recent nature of my dedication to MVC design, and to Catalyst's fat-model pattern specifically, has left me with some questions that I hope you folks can help me with. I'm trying to understand how I would go about moving my application's business logic, which seemed at first glance to fit quite logically into Catalyst's Controllers, into the Model. Specifically, in this case I've got a Catalyst::Model::DBIC::Schema model to obtain my application's data from; should I try to implement my business logic in that model (and if so, where? In the DBIC model PM? In the schema definitions?), 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
jralbert@uvic.ca

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

Search Discussions

  • Hans Dieter Pearcey at Jan 21, 2010 at 5:53 pm

    Excerpts from Jeff Albert's message of Thu Jan 21 12:37:41 -0500 2010:
    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'm a big fan of this; when your application gets complex enough, trying to do
    everything in the ORM classes can lead you down the path of a lot of class
    methods and complex hash/array data structures.

    High-level abstractions that arise out of the interactions of your DB classes
    deserve their own classes.

    (If your application *isn't* complex enough, this can be pretty clunky, so it's
    not a trivial decision.)

    hdp.
  • Rodrigo de Oliveira at Jan 21, 2010 at 6:36 pm

    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?

    Cheers,
    Jeff Albert

    jralbert@uvic.ca


    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100121/68bae321/attachment.htm
  • Tomas Doran at Jan 22, 2010 at 7:31 pm

    On 21 Jan 2010, at 18:36, Rodrigo wrote:
    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.
    You can just use Moose in your DBIC classes..

    You end up double declaring stuff (which is non optimum), and Moose
    comes after DBIC (as you replace the simple dbic accessors with more
    complex Moose stuff), but it works fine..

    Cheers
    t0m
  • Jay Shirley at Jan 22, 2010 at 7:52 pm

    On Fri, Jan 22, 2010 at 11:33 AM, Tomas Doran wrote:
    On 21 Jan 2010, at 18:36, Rodrigo wrote:

    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.
    You can just use Moose in your DBIC classes..

    You end up double declaring stuff (which is non optimum), and Moose comes
    after DBIC (as you replace the simple dbic accessors with more complex Moose
    stuff), but it works fine..
    I haven't tried this yet, but just had the idea of using
    MooseX::Role::Parameterized to fetch the column info and create the
    Moose accessors in a role based on what is defined.

    Then, just define an extra type that corresponds to a Moose type, or
    just some basic rules (varchar/char => Str, etc)

    __PACKAGE__->add_columns( 'foo' => { datatype => 'varchar', extra => {
    type => 'Str' } } );

    I've been meaning to give this a play and see if it works... thoughts?

    -J
  • Rodrigo de Oliveira at Jan 22, 2010 at 8:31 pm

    Then, just define an extra type that corresponds to a Moose type, or
    just some basic rules (varchar/char => Str, etc)
    How about a metaclass? That way I could add DBIC metadata to my attributes.

    Like this:

    has 'name' => (
    metaclass => 'DBIC',
    is => 'rw',
    isa => 'Str',
    dbic => { data_type => 'varchar', size => 50, ... }
    );

    The Moose class would probably need to inherit from DBIx::Class somehow, so
    I can set the table name. But I guess this is just the opposite (use DBIC in
    Moose) from what you're suggesting (use Moose in DBIC).

    -rod
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100122/499ec585/attachment.htm
  • Jay Shirley at Jan 21, 2010 at 6:45 pm

    On Thu, Jan 21, 2010 at 9:37 AM, Jeff Albert wrote:
    Hi List!

    I?m a new-ish Catalyst developer, converted from the ranks of the
    HTML::Mason faithful, and the recent nature of my dedication to MVC design,
    and to Catalyst?s fat-model pattern specifically, has left me with some
    questions that I hope you folks can help me with. I?m trying to understand
    how I would go about moving my application?s business logic, which seemed at
    first glance to fit quite logically into Catalyst?s Controllers, into the
    Model. Specifically, in this case I?ve got a Catalyst::Model::DBIC::Schema
    model to obtain my application?s data from; should I try to implement my
    business logic in that model (and if so, where? In the DBIC model PM? In the
    schema definitions?), 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?

    Much in line with the other replies (especially hdp's), I tend to
    create composite modules that do the work if it spams multiple
    objects. If they only modify the DBIC class itself, or a direct
    relation, I put the logic in the ResultSet/ResultSource package. This
    usually ends up with those methods being called by the higher-level
    module, though.

    For the non-DBIC-based packages, I then use either
    Catalyst::Model::Adaptor or InstancePerContext, and in creating the
    instance I pass in the connected schema.

    This allows for some flexibility and doesn't impact things like unit
    testing outside of Catalyst.

    -J

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJan 21, '10 at 5:37p
activeJan 22, '10 at 8:31p
posts7
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase