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

Benjamin Martin benjamin.martin at ims-evolve.com
Fri Oct 8 08:19:11 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.

-Ben



More information about the DBIx-Class mailing list