5

What is a good method for loosely-coupled inter-controller communication in MVC/MVP?

For example, in a Quote, the user must create and add a new contact, or add an existing one.

They choose to create a new contact. When complete, the contact is added to the quote, and the UI returns the user to that quote. If they hit cancel, they are returned to the quote.

I want to re-use Contact elsewhere, thus it should not know anything about Quote. For example, if I create a contact from the contacts list, it should return there when done.

Here are some options that I have thought of:

  • ContactsController action calls ApplicationController.getNextStep(this) and the ApplicationController figures it out the next step on behalf of the ContactsController

  • ContactsController raises "actioncomplete" event or similar, and the ApplicationController is listening for this event, and calls the correct next step

  • QuoteController passes in a "baton" to ContactsController with the next step, which ContactsController calls when done

  • ContactsController raises "actioncomplete" event or similar, and the QuotesController is listening for this event, and calls the correct next step.

Do you have experience with these? Other ideas? Which will cause the fewest headaches in a big app?

Thanks!

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152

3 Answers3

1

Guess I will answer my own question. Hopefully, I get that sweet, sweet bounty.

Think about this from the perspective of sending your consultant employee out to a customer. He knows how to do his job, but he doesn't know what to do when he's finished. You want him to be flexible about what he does next.

Sometimes his boss sends him out. Sometimes the CEO does (he might not know where to send him after). Sometimes the client calls him in with an emergency (he definitely doesn't know where to send him after). Sometimes he just grabs a new task from the whiteboard.

He could do one of several things:

  • you could tell him to call the head office when he's done, and head office will figure it out for him. he doesn't need to know about any other people, just the head office phone number.

  • you could tell him what to do when he's finished, before he leaves. if he's gone for a while, his next task might have changed in the meantime.

  • you could tell him to post to facebook when he's done, head office will be looking for it, and will tell him what to do. head office would need to be watching for a lot of facebook posts from all their consultants.

  • you could tell his supervisor to to answer his call when he's finished, but then his supervisor needs to be in the office, and maybe he'll switch supervisors.

Personally, I would pass in a callback function. If that callback is null, the callee should ask the application what to do. That gives you some flexibility, while also allowing for a parent process to manage things, and not relying on one big function in the app.

This would be equivalent to giving the consultant the number of the next customer to call, when he's done. If he doesn't get a number, he calls the head office.

You could use an event as well, and it's not a bad idea. The only issue might be if multiple objects are listening for this event, something untoward might happen.

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152
1

You could implement some form of navigation stack, where the Quote or Contacts controllers are first pushed into it, and then they push the Contact controller into it when required. When the Contact controller is done, it pops itself off and peaks at the next one to know where to go. This way it is completely decoupled and can be re-used everywhere, and can be nested n-levels deep.

Tyson
  • 14,726
  • 6
  • 31
  • 43
1

If I understand your question correctly, you have an action neatly encapsulated by a controller, and you'd like to ensure its post-execution behavior can be defined as dynamically as possible.

Your idea of a callback function is very good, but I'd go a step further and make it a Func<>, allowing you to utilize closures. I'll expand on your consultant metaphor: instead of passing a phone number to your rep, instead have him connect back to the office and get instructions from there. The beauty of using closures is that you can access the calling context directly from code otherwise out of scope; in other words, the closure can access all of the variables and functions in the host controller.

When your salesman is done with his task, he merely opens his briefcase (Func<>) and reaches into his desk at the office to see if anyone has put a To-Do item in his office drawer.

Jon Skeet (also on StackOverflow) has a great resource here: http://csharpindepth.com/articles/chapter5/closures.aspx

Brandon
  • 308
  • 1
  • 2
  • 10