ASP.NET MVC Portable Areas - Can they communicate and be used as a plugin-like architecture?

Question

I'll get straight to the point: I was wondering if there is a common pattern to use portable areas as a components of a plugin-like architecture.

Example: We've got 3 plugins (portable areas) packaged and distributed via NuGet feed. Each of them is following the standard MVC structure (has it own Models, Views and Controllers). Lets say login form, header and footer.

What I was wondering if there is a way to make them communicate. For example: when user logs on, login plugin executes it own logic, logs the user and then it updates the state of the header plugin with changes it state accordingly.

Edit: Dealing with client side calls Another thing that I did not mention in the original post is that I wanted to expose the plugin features via controllers to be consumed via JavaScript as well. Lets say I have all architecture in place and all plugins registered themselves with the system properly (routes, dependencies ...etc) For example if I click the "Change color" feature of one "Colors picker" plugin it calls action method of another plugin (Image plugin lets say) and loads image of requested color. Of course everything should be done via Ajax without resubmitting the entire page that hosts the components.

You think it is a doable scenario in the solutions you've proposed here?

Thanks in advance for all the answers.

• Robert Harvey: Normally, such communication would be done through the data repository (i.e. your model, via the database). Unless it's a ton of data or you need it to be really fast, and you never intend to save it.
• Beton: Thanks for your answer Robert. You mean that all areas (plugins) should modify common, shared and DB persisted data repository (model) ? In my scenario I've got a page (with its own model, view and controller) that hosts the plugins and calls their action methods to render the partial views of the components (areas).

Answer 1

I would not use a shared database where all plugins has write access since that makes debugging extremely difficult. There is no way to tell which plugin screwed up.

The best solution today is to take advantage of an inversion of control container.

1. Let each plugin have a separate assembly (separated interface pattern) where it declares it's integration interfaces (that other plugins uses)
2. Allow each plugin to have a composition root where it registers it's services
3. Then simply let every plugin use dependency injection to use the services which was specified by other plugins.

Another way is to use commands and domain events as I describe here: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/

Do note that it's not really portable areas specific.

If you're interested in a MVC3 plugin architecture I've made one using my Griffin.MVcContrib project: http://blog.gauffin.org/2012/05/griffin-mvccontrib-the-plugin-system/

• Beton: Very interesting jgauffin - gonna check it out. Thank you. Edited my original post as I have one doubt left. If you would check it out I would be grateful.
• Beton: Great blog by the way. A lot of useful stuff there. Sub-d.
• jgauffin: should be doable if it's doable in a regular MVC app.
• johnny: @jgauffin Does this mean you are saying not to use Areas in the first place? I'm late and only recently read about it. Should I not use it?
• jgauffin: areas work fine. But can be troublesome if you start using attributebased routing.