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

Will Hawes wdhawes at gmail.com
Fri Oct 8 12:06:02 GMT 2010


> 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.



More information about the DBIx-Class mailing list