[Dbix-class] Encapsulate multiple steps for insertion

John Napiorkowski jjn1056 at yahoo.com
Fri Jan 12 16:29:46 GMT 2007


--- Richard Jolly <Richard.Jolly at bbc.co.uk> wrote:

> Brian Kirkbride wrote:
> > John Napiorkowski wrote:
> >> --- Tobias <list at funkreich.de> wrote:
> >> 
> >>> Hi everybody,
> >>> 
> >>> I'm writing a forum application with DBIx::Class
> and Catalyst. Every
> >>> post in a forum is stored using two tables (for
> performance
> >>> reasons): 
> >>> 
> >>>   * posts - (DBIC class "Forum::Post")
> >>>     contains basic data for every post
> >>>     has_one relationship with Forum::PostText
> >>> 
> >>>   * post_texts - (DBIC class "Forum::PostText")
> >>>     contains just the texts
> >>>     belongs_to Forum::Post
> >>> 
> >>> I'm wondering what's the best way to encapsulate
> this because I
> >>> don't want to make calls to several DBIx::Class
> classes everywhere
> >>> I want to insert a new post (i.e. in Catalyst
> controllers). Should
> >>> I just create a third class outside the Schema
> namespace which
> >>> utilizes all neccessary DBIx::Class classes for
> inserting a new
> >>> post to hide the underlying separation into two
> tables from the
> >>> rest of the application? What I want is to call
> _ONE_ method in my
> >>> Catalyst controllers to insert a new post into
> the database. The
> >>> controller shouldn't worry if the data gets
> stored in one, two or
> >>> ten tables. 
> >>> 
> >>> Maybe there's some sort of DBIx::Class magic to
> do this without
> >>> having to add an extra layer myself?
> >>> 
> >>> Thanks for any suggestions!
> >>> 
> >>> --Tobias
> >> 
> >> I think there are two (or two and a half) ways of
> dealing with this
> >> that I've seen kicked around are:
> >> 
> >> 1) Add some methods to your DBIx::Class files. 
> For example you can
> >> write a method called create_post that would be
> attached to the post
> >> class that would insert into both tables for you.
> >> 
> >> I've heard this method called the "ActiveRecord"
> >> pattern, since you are combining your physical
> model (the object that
> >> maps to a table) with a business model (that
> encapsulates your
> >> business rules). 
> >> 
> >> 2) Create a custom Catalyst Model that offers
> methods for your
> >> business rules and creates it's own DBIx class
> objects as part of
> >> it's instantiation. 
> >> 
> >> 2.5) like 2) but instead of the object being a
> catalyst model you
> >> make it a plain Perl object (or use a OO
> framework like Moose) and
> >> then have a very simple Catalyst model
> instantiate it for you.
> >> 
> >> I tend to do 1) because it's easy and makes it so
> that your business
> >> rules are not just inside catalyst (you can use
> them for CRONS, etc).
> >> I would like 2.5 for the same reason but I'm not
> sure about the best
> >> approach.  I'm hoping someone with a better grasp
> of MVC best
> >> practices eventually releases an example :) For
> example I can see if
> >> you really get Moose you could create a business
> object rule that all
> >> your business classes you and then you are sure
> of the way it would
> >> work.  This is the generally the approach that
> J2EE uses; they have a
> >> bean object that uses an interface for this, I
> think.
> >> 
> >> I think 1) is okay for rules that work primarily
> on a single table or
> >> on tables that are related.  But ideally you
> should have a separate
> >> domain object for each class of business rule, or
> at least that is
> >> what I am gathering from my reading of the way
> MVC is handled in
> >> other frameworks.  This way you get better
> reusability and can
> >> compose your objects best.  I think it would also
> fit into the work
> >> being done on Reaction (although please don't
> quote me on this, I am
> >> still reading and re-reading reaction source)
> because if you have a
> >> business object with a defined interface that
> would make it easier
> >> to hook it to the UI model through Moose's
> reflection.  Sounds
> >> great, wish I know how to make it work :) 
> >> 
> >> Will be watching this thread with interest.
> >> 
> >> --john
> >> 
> > 
> > 
> > Solution 2.5 works very well for me:
> > 
> > - access to business model logic outside of
> Catalyst
> > - easy access from within Catalyst (integrated
> with ACCEPT_CONTEXT)
> > - it wouldn't be too hard to switch out the data
> model (DBIx::Class)
> > 
> > After a discussion on this list concerning the
> > differentiation between data model and
> business/domain model
> > this seemed like the consensus.
> 
> Do you have any pointers to threads? Some quick
> searches on 'domain
> model' and 'business model' didn't bring up much.
> 
> We use what is described as the ActiveRecord
> approach above, and I'm not
> that happy with it. It works well enough but the
> intent of the code is
> not clear.
> 

I have the same problem with it, for non trivial apps
you end up with a mess of unrelated methods in one
class.  Plus you can't easily factor out common
business rules and you end up with too much cut and
paste stuff.  To some degree you can help this problem
by using DBIC components, but I tend to want my custom
components to not have anything to do with business
rules.

> But I'm not sure what making a set of domain model
> classes would
> actually look like.
> 
> Richard
> 
> 
> > Cheers,
> > Brian
> > 
> > _______________________________________________
> > List:
>
http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> > Wiki: http://dbix-class.shadowcatsystems.co.uk/
> > IRC: irc.perl.org#dbix-class
> > SVN:
>
http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> > Searchable Archive:
> >
>
http://www.mail-archive.com/dbix-class@lists.rawmode.org/
> 
> 
> 
> _______________________________________________
> List:
>
http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN:
>
http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> Searchable Archive:
>
http://www.mail-archive.com/dbix-class@lists.rawmode.org/
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com



More information about the Dbix-class mailing list