Not to say that decorators (or any other single pattern) is a
panacea. Often it is hard to achieve what you want simply by
intercepting public methods, but I've always ran into problems when
designing and coding delegate extension points...
Andrus
On Jun 5, 2007, at 5:57 PM, Andrus Adamchik wrote:
[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
