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/[email protected]
