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

[Dami Laurent (PJ)]

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

Best regards, L. Dami