OO advice ... do a subclass? .. do something else?

[Benjamin Martin]

Morning all :),

I would like to ask the experts for some advice on how I might tackle
the problem below... so please let me have your thoughts.

I have currently have a pretty typical dbix::class schema of tables and
relationships.

Within my schema I have a table of tickets .. basically support/trouble
tickets.

A ticket can exist as a single entry in one table, but also certain
'types' of tickets will always have certain relationships... I guess
this is "business logic" and it is not enforced by the database.

My question is "what is the best way to deal with this?"

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.

I am not really liking this approach as not only do I need to add a
method to deal with each 'type' of ticket, it does not seem very
extensible and could lead to a mass of code in the ResultSet.. I am sure
there is a better way.

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.

-Ben

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Will Hawes]

> Morning all :),
>
> I would like to ask the experts for some advice on how I might tackle
> the problem below... so please let me have your thoughts.
>
> I have currently have a pretty typical dbix::class schema of tables and
> relationships.
>
> Within my schema I have a table of tickets .. basically support/trouble
> tickets.
>
> A ticket can exist as a single entry in one table, but also certain
> 'types' of tickets will always have certain relationships... I guess
> this is "business logic" and it is not enforced by the database.
>
> My question is "what is the best way to deal with this?"
>
> 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.
>
> I am not really liking this approach as not only do I need to add a
> method to deal with each 'type' of ticket, it does not seem very
> extensible and could lead to a mass of code in the ResultSet.. I am sure
> there is a better way.
>
> 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.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Brian Phillips]

On Fri, Oct 8, 2010 at 7:06 AM, Will Hawes <[hidden email]> 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...

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Benjamin Martin]

On 08/10/10 15:58, Brian Phillips wrote:
> TMTOWTDI applies...

very true! :) ...

I definitely have something to think about now.. and some stuff to read.

thanks very much for the replies, I really would feel quite lost without
the excellent Perl community guiding me


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...