[Catalyst] The model -is- where your business logic lives.

[Matt S Trout]

On Fri, Sep 28, 2007 at 09:22:01AM +0200, Dami Laurent (PJ) wrote:
>  
> 
> >-----Message d'origine-----
> >De : Matt S Trout [mailto:dbix-class at trout.me.uk] 
> >Envoyé : jeudi, 27. septembre 2007 22:44
> 
> >Don't confuse class -names- with the nature of classes. 
> >MyApp::Model:: is
> >*adapters* that make a model available to MyApp, not where 
> >your domain model
> >logic itself should live.
> >
> >I usually these days have MyApp::Web for the catalyst app 
> >instead of MyApp so
> >I can deploy things like MyApp::DataStore from a separate dir tree.
> 
> 
> Makes a lot of sense to me. So the model can be used not only from the catalyst App, but also from batch jobs, command-line utilities, etc. And the Catalyst model *adapters*, as you call them, merely load the appropriate external modules, that's all.
> 
> But then comes a question about writing Catalyst code : which is best between a) and b) below ?
> 
> # a) go through the adapter for every method call
> $c->model('Some::Model::Adapter')->do_stuff()  
> 
> # b) directly call the external model after it's loaded
> My::External::Model->do_stuff()                 
> 
> 
> I tend to prefer b) because the code dealing with business logic always looks the same, either within the Catalyst app or within the command-line utilities. And if there is some global state in the external model (like sharing the DB connection, or setting/changing properties on that connection), it makes it very clear to every client that they are interacting with the same common global state. Finally, it saves a couple of method calls.
> 
> My colleague prefers a) because it's the usual, "oficial" Catalyst way, and because if we ever need some reverse interaction from the model to the controller, we can add stuff in the adapters, playing with ACCEPT_CONTEXT.
> 
> Any other opinions in this debate ?

I always use approach (a) because I don't tend to deal in terms of class data.

Personally, if you can call

My::External::Model->do_stuff()

then clearly you're using class methods to hide magic global variables. I
don't really believe in magic globals.

DBIC models simply -can't- function that way of course, since we don't do that.

In the case of Model::DBIC::Schema of course

$c->model('Foo::Bar') is just convenience for

$c->model('Foo')->schema->resultset('Bar')

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