On Wed, May 18, 2011 at 12:48 PM, Eden Cardim <[email protected]> wrote: >>>>>> "Octavian" == Octavian Rasnita <[email protected]> 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 _______________________________________________ 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/
