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

[Zbigniew Lukasiak]

On 9/28/07, Dami Laurent (PJ) <laurent.dami at justice.ge.ch> wrote:
> >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 ?
>

Hmm - I thought most models are objects.  Perhaps this was wrong
assumption (but at least the DBIC::Schema is) - but how do you do
connection pooling if it is not?

Cheers,
Zbyszek
http://brudnopis.blogspot.com/