[Dbix-class] Encapsulate multiple steps for insertion

[John Napiorkowski]

--- Brian Kirkbride
<brian.kirkbride at deeperbydesign.com> 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)

Am interested in why you should integrate via
ACCEPT_CONTEXT instead of by overriding 'new'.  Is is
because you need to instantiate a new object each
time, or because you actually need the context for
your model?

This is probablt getting way offtopic for the DBIx
mailing list, but one thing that I've always had
trouble understanding is the best way to integrate my
custom catalyst models with DBIx.  I see from looking
at a lot of the CPAN source for Catalyst Models that
most people override one of
new|COMPONENT|ACCEPT_CONTEXT, instantiate their
external object and then put it in a local accessor
like.  But then you get a bit of uglyness in using the
model because you have to use that accessor each time
like:

$c->model('MyModel')->my_obj->method1;
$c->model('MyModel')->my_obj->method2;

So I can see that people have come up with a couple of
ways to deal with this.  I notice that the Handel
Catalyst stuff uses AUTOLOAD to deal with this, but I
can see the DBIx Schema Model uses ACCEPT_CONTEXT. 
How are you all creating Catalyst models for method
2.5?

Thanks!
John



> - 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.
> 
> 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/
> 



 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited