On Friday, September 26, 2003, at 09:48 PM, Dirk Olmes wrote:
>> Current OperationObserver already combines too many things from
>> different areas of Cayenne. Besides the main flow of query execution
>> relies on particular implementations of Observer, so it is not good
>> for custom delegation. Another alternative - using DataContext events
>> - (that we discussed with Dirk and Holger) is not satisfactory to me
>> either (though some would probably disagree with me on that :
>> http://objectstyle.org/cayenne/lists/cayenne-devel/2003/09/0005.html
>> ).
>
> Err, could you please explain why? When inventing the whole
> DataContext event machinery at least I had a large number of uses in
> mind, including events that were to be consumed internally by cayenne.
> Since you mentioned multi-threaded dispatch before: do you intend the
> DataContext events to act as a bridge to user code only?
> Now, that I think a little bit more about the willPerformQuery use I
> see that this is really more a delegate in the pure EOF sense: some
> object that is called before a certain operation is executed and that
> object has the chance of vetoing/influencing the flow of control. The
> question that pops up now is: by which criteria do we distinguish
> between which method calls go into the delegate interface and which
> will be posted as events?
> Maybe we can refactor the DataContext events a little bit more to
> match your requirements?
Since we started this discussion, I think we should take a step back
and do a more systematic design of the access layer events and
delegation tasks instead of current ad hoc approach. I guess we may
start with some definitions (even if they may seem obvious) and work
from there.
1. Delegation.
Delegation is a very generic pattern (calling one method from another
is delegation if you think of it). In our case we are interested in a
more narrow definition:
Cayenne access layer implements a predefined sequence of steps for
every supported operation. "Delegation" is temporarily passing control
of the execution to an object external to Cayenne ("delegate") at some
critical points in this sequence. Delegate can either alter the flow
(by following the contract of a given delegate method - throw an
exception, return a certain value, etc.), and/or change the state of
objects participating in the operation, and in general do whatever it
feels like. This is very close to the EOF definition of the delegate,
but is definitely not specific to EOF. A "delegate" is external to
Cayenne framework (we may not even force the implementation of certain
interface to make it easier to create delegates that implement only one
or two methods).
2. Events.
Completion or failure of a certain step of some Cayenne operation may
be of interest to the outside observers, as well as to the other
objects in Cayenne. Events will be dispatched to the registered
listeners. In general listeners notification is decoupled from the
thread that generated the event.
Consequences of the above definitions:
a. If something is a standard feature in Cayenne, it should not be
implemented via delegation (i.e. object validation)
b. Delegate however can ban the execution of certain steps in a
sequence, or abort the whole operation.
c. Public delegation API should only be used externally. Cayenne will
not implement delegates in the framework.
d. Events can be used by both internal and external listeners.
e. Event listeners are normally decoupled from the event source and
can't prevent the operation that generated the event from happening.
f. ... ???
Example of delegation: DataContextDelegate.willPerformQuery.
Example of event: SnapshotEvent that I am currently working on.
I am planning to get back to the design of this features in a while,
after I am done with snapshot caching feature. But nothing prevents us
from discussing it now :-)
Andrus
This archive was generated by hypermail 2.0.0 : Tue Sep 30 2003 - 14:09:28 EDT