Just doing some work on my business model. Basically I have a problem with the event pattern (well a few, but one I'm specifically interested in right at the moment).
The problem is that I'm sending blocking event notifications 'when the event happens', and I don't want to do this.
In the MVC like pattern that I'm implementing, I need my model to alert my view to changes. The thing is that I don't want to interupt processing on the model while I wait for the view to do what it needs to do to update.
I'm only just opening up this can of worms now, so here's some initial thoughts (for my benefit).
Basically, I'm thinking about events like this:
[Noun]Has[Action]ed // happened some time ago, but I'm telling you now
[Noun]Will[Action] // the action is happening immediately after this event
[Noun]Just[Action]ed // this event is raised immediately after the action
I'm not sure about all this yet. I think a naming convention is particularly important for the first type 'Has' events. Because a whole heap of 'other' things might also have happened. The real purpose of these is for the View to update itself, *at an appropriate time*.
The other thing that I've decided is that: I don't want to use an event if I want a delegate.
The reason I made the last point is that I defer some processing at run-time internally to a dynamically selected method. In some cases I've gone about this by using an event and then handling it. I want to avoid this. In this way I prefer to think of an 'event' as a 'notification' and a 'delegate' as a 'command'.
The thing about 'Will' and 'Just' type events is that often they do need to be processed synchronously, particularly 'Will' types as they often pass event args that provide a mechanism to cancel (i.e. Will => Oh, no you will not!). Thus 'Will' and 'Just' type events stand out as 'more than just a notification', because they can impact on the code path in 'undefined' ways.
Anyway, I'm going to meditate on this one. I need a mechanism for queing and dispatching 'Has' type events at an appropriate place. The big advantage of this is that I'll be able to expand on this to support code execution off the UI thread, on a 'model' thread. What I've really done is couple the 'Model' and the 'View' more like a client/server, but the client can still block the server *if it must*.
The idea will be that 'Has' events will execute on the UI thread, and the 'Will' and 'Just' events will execute on the Model thread. If something needs to happen in the UI as a result of 'Will' or 'Just' events, then I envisage that the process will be to register a handler, and do a blocking invocation onto the UI thread.
John.