Q:

Design Pattern For UI Control and Provider to Call Control's Events

I have a UI control that uses a provider class to implement the actual logic of a complex task.  So the control delegates to the provider to do some work.  But the provider needs to work with the control too; it needs to fire some events on the control.
I was looking for a good design pattern of how the two could work together, but wasn't sure of any.  I didn't want the  provider to directly invoke events on the control.  I thought about methods on the control that it could call, but I don't know that I quite like that either.
Any ideas, thoughts?  What is a good design pattern that the provider can use to fire a notification through the control?  Each event may also need to pass custom parameters too.

A:

I can think of two models:
Using callback functions
If your language supports passing functions as parameters, then you can call the provider's method from UI, passing it a function to be executed at the appropriate point. C# and JavaScript support this method. The code can be something like this:
provider.DoSomething(successCallback);
function successCallback () {
    // This function is written in UI and belongs to UI, but would be executed in provider.
}

Using events
In this model, you can expose custom events in your provider to the external world. This way, you can provide event handlers for those events in your UI. For example, imagine that a provider tries to validate an order. This provider can expose an event called OrderValidated to the external world, and UI is just something existing in that external world. UI on the other hand can provide a handler for that event called HandleOrderValidated. In fact, UI subscribes to an interesting moment of the internal life-cycle of provider, and when that interesting moment comes to reality, provider informs any subscriber, and each subscriber takes its own action.

