DBIx::Class - Related Tables

[Matt S Trout]

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

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?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/