[Catalyst] Model Instances vs. Model Classes - Round 2

[Alejandro Imass]

On Wed, May 18, 2011 at 1:42 AM, Octavian Rasnita
<octavian.rasnita at ssifbroker.ro> wrote:
> From: "Alejandro Imass" <alejandro.imass at gmail.com>
>>
>> 3) It is written somewhere (I couldn't find it before writing this but
>> I know is in the POD somewhere) that it is not a good idea to pass the
>> complete $c reference to the per-request object, but rather only the
>> necessary pieces of $c. What are the implications of passing the
>> complete $c ?
>
>
>
> If you pass the context $c to the business model, and the business model
> would need to access the attributes and methods offered by $c, then you
> won't be able to use that business model outside of Catalyst because you
> won't have the context variable available.
>
> Octavian
>

Thanks for your prompt reply. Absolutely agree. For example, even
stuff like loggers, etc. should be kept independent of Catalyst, that
is clear to me. But my question is specific to the Catalyst Model
"Instance" (pattern #2 in my OP). That is, the the model instance is a
factory that spawns smaller per-request objects vis the ACCEPT_CONTEXT
method. This is all catalyst, since in this pattern it must be assumed
that the business model classes are instantiated as long-living
objects in the factory class, probably as attributes (Refs) of the
Catalyst Model Instance.

In other words, the business code should be instantiated by the
factory class, for example: a business model class would be
instantiated as an attribute (type Ref) of the Catalyst Model Instance
so the business logic is loaded only once, and does not have to be
loaded per every request and then thrown away. This also means two
things which is what I would like to verify with you here:

1) The per-request objects (the ones spawned by the Catalyst Model
Instance in ACCEPT_CONTEXT) forcibly need a reference to the factory
class so they can access the business model objects that were
instantiated upon start-up.

2) The business model classes need to receive all the information
needed, that-is the data structures of the per-request information
that live in the smaller per-instance objects. This pattern allows you
to pre-load all your business logic in the factory class and
effectively de-couple the business logic from Catalyst.

Anyway, that's whay I see as the whole point of Catalyst Instances,
mean that you can pre-load as much of the business code in RAM and
only spwan very small clases per-request that are basically all data:
that is the methods of these per-request objects should actually be
calling methods in the pre-instantiated code in the factory class (the
Catalyst Model instance).

This makes the Model Instance a wrapper of business class and itself
can be modelled in two ways:

1) The methods of the factory are wrappers of private business class objects.
2) The business classes are references modeled as attributes of the
factory class and invoked directly by the per-request objects.

I just want to make sure these suggested patterns are not doing
something horribly stupid that would make the app useless in a
multi-threaded env for example (i.e. *NIX mod_perl + mod_worker).

Maybe I should craft up some sample code of the three patterns identified:

1) Catalyst Models Classes: that completely instantiate per request.
2) Catalyst Model Instances: with wrapper methods
3) Catalyst Model Instances: with wrapper attributes

In both 2 and 3, business objects as such are instantiated when the
Catalyst Model is instantiated. The difference is how to expose the
business objects to the per-request objects spawned by ACCEPT_CONTEXT.

Why am I doing all this? Because if you look at the books that
currently exist about Catalyst, the POD and the Wiki, honestly there
are no simple and down to earth explanations on Catalyst models, just
a lot of blurb on "what" are the best practices but no so much "how"
they should be accomplished and with clear down to earth examples for
the mere mortal.

I'm willing to do the work but first I want to make sure my conceptual
framework is correct. I think there should be some clear code examples
with the different patterns to actually achieve these best practices.

Best,

--
Alejandro