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

Alejandro Imass alejandro.imass at gmail.com
Thu May 19 08:04:49 GMT 2011


On Wed, May 18, 2011 at 12:48 PM, Eden Cardim <edencardim at gmail.com> wrote:
>>>>>> "Octavian" == Octavian Rasnita <octavian.rasnita at ssifbroker.ro> writes:
>    Octavian> If you pass the context $c to the business model, and the business model
>    Octavian> would need to access the attributes and methods offered by $c, then you
>    Octavian> won't be able to use that business model outside of Catalyst because you
>    Octavian> won't have the context variable available.
>
> Technically, that isn't true. Given this is perl, we don't have implicit
> type-checking, so you can always use duck typing, ie, build a class that
> mimics all the methods available to $c and sons. The real issue is that
> your API will be laden with web-based semantics, not business
> semantics. The focal point of me bringing this up is that the
> implementation is barely what matter in a discussion like this, it's
> always about the API semantics.
>

Yes. In fact there is a lot of stuff I forgot to mention in the
postulated patterns. What I have been doing is standardizing an
'entity' data structure that _is the api_ between the cat/web-based
semantics and the business logic. The concept of 'state' goes well
with business class and with Web/REST

The 'entity' is instantiated by the per-request object and accumulates
transactions and data during the execution of the request. It's a
pure-perl/Moose object that is passed back and forth and in the end is
returned to the controller for rendering. It has methods to return
itself ->as_hash for example so it can be digested by a TT view or
methods as_json if you are not using something like CC::REST.

Usually most business logic revolves around some sort of state
machine, workflow so it's basically tracking entering state,
intermediate states and transactions and a resulting state. As stated
This abstraction also pairs well with both EPC (Event Driven Process
Chains) and with REST ;-) (i.e. the entity is a whole and represents
it's state, the entity can be a data object or a business process
object).

What I'm not exactly sure is about the way we are using Catalyst Model
Instances. For us all this trouble of instances is mainly to load as
much business logic code as possible when starting the app and
minimizing the per-request loading and unloading of heavy-duty code.
The questions mainly revolve around this (see my OP).

--
Alejandro Imass



More information about the Catalyst mailing list