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.

closed as too broad by gnat, user40980, Robert Harvey, Kilian Foth, Dynamic Nov 23 '13 at 0:03

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    What exactly is wrong with your proposed solution of coupling controls to providers? If you think the coupling is too tight then you could abstract the control event interface and plug in the proper proxies for the controls but this adds extra complexity and indirection and is actually premature optimization which I hear is evil. – davidk01 Jul 15 '11 at 20:48
  • classic MVC pattern applies here – Steven A. Lowe Jul 15 '11 at 21:28
  • @davidk01 It's more that I feel the coupling of the provider to the explicit control reference, and making the On<Event> methods internal/friend so that the provider could call it. Making them public didn't feel right. – Brian Mains Jul 16 '11 at 0:34

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:

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.