Extension of MEF

Jan 13, 2010 at 6:32 PM

Hi

I'm playing with MEF since a few days, and I have a bunch of questions !

I read your article (http://blogs.msdn.com/gblock/archive/2009/11/01/should-i-use-mef-with-an-ioc-container-part-1.aspx), and I totally agree with you.

Let's take an exemple : I'm in a company and I'm developping a library.

I want to use another library. This library internally uses an IoC.

We want to use MEF for exposing objects managed by IoC to the others. Others should not have anything to deal about What's in IoC.

Tell me if I'm wrong, but MEF actually expects a default constructor for each object to export.

After trying to subcast some classes (ExportDefinition, ComposablePart, ...), I have the following remarks :

  • Lots of code inside the classes Reflection*(ComposablePartDefinition, Export/ImportDefinition) are not specific to the "reflective" way of instantiating MEF parts. But you need to rewrite all that code. It may be a good way to have an parent class you can inherit for cusomizing only instantiation.
  • I also take the approach of creating my own ComposablePartCatalog, but I still have the impression of rewriting all "reflective" code by changing the lines "Activator.CreateInstance()".

I look on MEF contrib the "Programming Models".

There are very good ideas in it, as the ObjectFactories.

I think it should be easier than that to replace the default MEF behaviour of instantiating exported services. I think that the method CreatePart of AttributedModelDiscovery, should not return always a ReflectionComposablePart, but there should be some way of easy customisation of that. You could want to expose WCF Services using MEF for example. Something around the p&p ServiceLocator for exporting would be nice.

And a last question : why ExportAttribute does not match with ExportDefinition ? Attribute has ContractType, not Definition ? Same thing on Import.

I'm interested in everybody point of view.

Thanks.