tags:

views:

95

answers:

3

We have a number of plugin applications that can all run independently but also can run within the same host container. Users can run one single host container or multiple ones with one or many plugins.

We have a number of "integration" use cases where people want to either

  1. Send data from one plugin to another
  2. Send "actions" or "commands" to another app (sometimes with parameters)

We have a couple of options:

  1. Have a well known event bus at the container level that all plugins know about and can publish and subscribe well defined messages or objects

  2. Embed the dlls of one into another and call the API of one plugin from another

  3. create integration plugins that know about the common integration points so each individual plugin is completely standalone and the integration plugin is the only thing that knows about the integration. This was we can ship each individual plugin without any extraneous dependencies.

Thoughts or other suggestions?

A: 

Consider Microsoft's Patterns and Practices Composite Application Guidance for WPF and Silverlight. Even if it is not exactly what you need, it would be a good pattern to learn some methods for accomplishing some of what you need for modularity such as sharing data between modules.

Doug L.
+1  A: 

The Smart Client Software Factory is another bit of guidance to consider. It's WinForms for the most part and perhaps slightly more complex than the newer WPF release (which was completely re-architected). However, it would also give you ideas to accomplish your modular goals. The links and documentation do a good job of covering how modules are separate, but can pass data through the common framework.

Doug L.
+2  A: 

I would take a look at the new Managed Extensibility Framework (MEF) library currently being developed by Microsoft. See the Codeplex site. As I understand it correctly VS 2010 will also use this framework to provide extensibility point in Visual Studio.

FromTheMountain