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.

  • 1
    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. – Robert Harvey Oct 20 '12 at 17:21
  • 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). – Beton Oct 20 '12 at 18:10

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/

  • 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 Oct 21 '12 at 8:40
  • Great blog by the way. A lot of useful stuff there. Sub-d. – Beton Oct 21 '12 at 8:59
  • should be doable if it's doable in a regular MVC app. – jgauffin Oct 21 '12 at 10:18
  • @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? – johnny Dec 16 '16 at 15:53
  • areas work fine. But can be troublesome if you start using attributebased routing. – jgauffin Dec 16 '16 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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