[taking to dev]
Delegation model hardcodes a preset number of extension points and
adds a fair amount of internal code registering delegates and
integrating them into the flow. I saw it falling apart many times
when trying to extend/change things in the stack.
An alternative is to define all main stack components as interfaces,
and allow both end-users and Cayenne developers to write decorators
(as in "decorator pattern") to build loosely-coupled functionality
layers. Decorators (or interceptors, or wrappers) follow the natural
structure of the stack interfaces, do not require special hardcoded
flow, and generally do not increase internal code complexity
(allowing for better modularity). Think of that as a cheap version of
AOP or Objective C categories.
BTW, JPA callback API itself is an example of the delegation model,
which is fine - I think this is an example of its appropriate use.
While for instance DataContextDelegate is questionably less flexible
than an ObjectContext decorator.
Andrus
On Jun 5, 2007, at 4:47 PM, Lachlan Deck wrote:
> On 05/06/2007, at 10:31 PM, Andrus Adamchik wrote:
>
>> On Jun 5, 2007, at 3:22 PM, Lachlan Deck wrote:
>>
>>> Perhaps it'd make sense to be able to register a delegate... then
>>> you can still separate concerns ;-)
>>
>> Could you elaborate some more?
>>
>> Most often than not I find the EOF-like delegate approach to be
>> rather inflexible
>
> In what sense? I find it's a good fit when you need to insert some
> shared logic within the call logic. However...
>
>> , and certainly not suitable for the framework internal needs.
>
> The other option presented in EOF which is also useful is that of
> notifications. The difference between the two is usually that the
> delegate can abort an operation or provide custom shared behaviour
> whereas numerous objects can register as notification observers to
> run their own logic based on the transpired events. So perhaps
> notifications could be a good choice as any object can register
> themselves as an observer of a notification, registering the method
> to call when the notification is fired, and whether to limit the
> notification to those fired from a particular object or for any for
> that key. This seems to me to suit the lifecycle events nicely.
>
> Not only do individual PersistentObjects need to be notified of
> prePersist/postPersist etc but I find it useful (in the EOF space)
> of receiving a notification, when an editing context has been
> saved, that provides with the notification the list of objects
> deleted, inserted, and updated so as to deal with them as a group
> (which could handle fulfilling the former by interating through the
> objects can calling pre*/post*). But being able to register any
> object against these various lifecycle events ought to provide for
> additional flexibility.
>
> Btw, I'm thinking that PrePersist ought to be run just prior to
> persisting an object (as the name suggests) and that another
> postCreate lifecycle event ought to take its place. What do you
> think? That seems to be the missing piece in the puzzle between
> validateFor* and committing a new object.
>
> with regards,
> --
>
> Lachlan Deck
This archive was generated by hypermail 2.0.0 : Tue Jun 05 2007 - 10:58:15 EDT