DBIx::Class - Related Tables
Matt S Trout
dbix-class at trout.me.uk
Tue Oct 7 18:23:42 BST 2008
On Tue, Oct 07, 2008 at 11:37:19AM +0100, Andy Wardley wrote:
> The approach that I have found works best (for me at least) is to have
> one module for each table in the database (subclassed from a generic
> DB::Table module), and another for each record (subclassed from a generic
> DB::Record module). using one class for both table and record is broken,
DBIx::Class actually goes one step further - we have ResultSource (table/view),
ResultSet (query/dataset/whatever) and Result (row/record/etc.) and all
three are independently subclassable.
So really the only reason to end up with DB logic poking through when using
DBIC is to make the decision not to bother fully abstracting because it
isn't worth the effort. For simple applications this can very much be a
valid decision to make.
So while I appreciate and approve of all your comments, I do need to make
clear that they don't apply to DBIx::Class really except where the user has
chosen to allow them to apply for speed of development.
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
More information about the london.pm