On 9/28/07, Dami Laurent (PJ) <[EMAIL PROTECTED]> 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/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
