views:

56

answers:

1

I didn't really know how to phrase the title of my questions, so my apologies in advance. I read through parts of the MEF documentation to try to find the answer to my question, but couldn't find it.

I'm using ImportMany to allow MEF to create multiple instances of a specific plugin. That plugin Imports several parts, and within calls to a specific instance, it wants these Imports to be singletons. However, what I don't want is for all instances of this plugin to use the same singleton.

For example, let's say my application ImportManys Blender appliances. Every time I ask for one, I want a different Blender. However, each Blender Imports a ControlPanel. I want each Blender to have its own ControlPanel. To make things a little more interesting, each Blender can load BlendPrograms, which are also contained within their own assemblies, and MEF takes care of this loading. A BlendProgram might need to access the ControlPanel to get the speed, but I want to ensure that it is accessing the correct ControlPanel (i.e. the one that is associated with the Blender that is associated with the program!)

This diagram might clear things up a little bit:

alt text

As the note shows, I believe that the confusion could come from an inherently-poor design. The BlendProgram shouldn't touch the ControlPanel directly, and instead perhaps the BlendProgram should get the speed via the Blender, which will then delegate the request to its ControlPanel.

If this is the case, then I assume the BlendProgram needs to have a reference to a specific Blender. In order to do this, is the right way to leverage MEF and use an ImportingConstructor for BlendProgram, i.e.

[ImportingConstructor] public class BlendProgram : IBlendProgram { public BlendProgram( Blender blender) {} }

And if this is the case, how do I know that MEF will use the intended Blender plugin?

+1  A: 

You should break it as mentioned. Expose your control panel through your blender as you say. If you really want to keep your current design, you'll have to decorate the import with metadata and make a custom export provider that will use this metadata to determine what export it should use. If you can get rid of this extra step, do it.

Julien Lebosquain
I figured I'd have to break that association because it just seemed like the right way to do it, but my other question remains -- how do I go about ensuring that the BlendProgram is associated with the correct Blender? Since MEF controls the resolving of both instances, does it automatically pass the right instance to the importing constructor, as I would expect it to "just know" that a specific Blender wanted to resolve that BlenderProgram?
Dave