[Dbix-class] Re: OO advice ... do a subclass? .. do something else?

[Brian Phillips]

On Fri, Oct 8, 2010 at 7:06 AM, Will Hawes <wdhawes at gmail.com> wrote:
>
> > [ snip ]
> >
> > Currently I have a method in my ResultSet class for tickets called
> > something like 'create_typeX' .. this method wraps the logic that
> > creates the ticket and all relationships for that type.
> >
> > [ snip ]
> >
> > I think I need to do a subclass of my ticket ResultSet?.. but I am not
> > sure and wanted to ask people who actually know what they are doing ;)
> >
> > Some stuff in my head is, should I sub-class my ticket ResultSet?..
> > should I somehow use a Role/Trait? .. should I have something that sits
> > ontop of my Schema and applies the business logic to it?
> >
> > Any advice/links/examples you can provide would be greatly appreciated.
>
> It sounds like http://search.cpan.org/~frew/DBIx-Class-0.08123/lib/DBIx/Class/Manual/Cookbook.pod#Dynamic_Sub-classing_DBIx::Class_proxy_classes
> could be along the lines of what you want.
>
Dynamic sub-classing only affects the Row objects returned by a single
ResultSet.  I think Will is interested in custom ResultSet objects.  I
would create a single abstract Result class defining the table and the
common columns used by all the various types and then create
sub-classes for each of the specific types that define the appropriate
relationships and any additional relevant columns for that ticket
type.  You can then do something like
$schema->resultset('Ticket::Foo')->create({ ... }) or
$schema->resultset('Ticket::Bar')->create( { ... } ) and get the
desired object type.

In my experience, roles have limited use for setting up Result classes
because without a lot of hackery, you can't call class methods within
a role (ala __PACKAGE__->table('tickets') ) so sub-classing seems to
work a lot better for this type of thing.

TMTOWTDI applies...