A shared model

Dec 31, 2008 at 2:55 PM
Edited Dec 31, 2008 at 3:02 PM
I'm quite new to MEF, but as far as I can tell, there is no shared model in MEF.

e.g. the AttributeModel has its _own_ model.

If you want to provide a new way to configure your dependencies, you have to provide a completely new model.

Why arn't there a shared extensible model that can be built up using different model builders?

e.g. having a builder that scans attributes on types and members and builds the model from that.
or a builder that reads an XML config and builds the _same_ model from that.

My impression so far is that you have to implement everything on your own in order to do this sort of things.

current approach ->

Assembly with annotations -> Attribute model

3rd party xml config -> 3rd party model


If this is the case I find it sort of strange.

I would like to see something like:

Assembly with annotations -> Attributed model builder
                                                                                          \
                                                                                             Shared extensible model
                                                                                         /
XML Config                     ->        XML config builder
  


I might be completely wrong here due to my very limited exposure to MEF, if so, just slap me :-)


Also, there are a crazy amount of "internal" classes in MEF, I do know that it's considered bad design to expose virtual and non sealed classes unless you know they are safe to inherit or override..
But having an "Extensibility" framework where almost every type in the framework is sealed or internal doesn't really open up for extensibillity IMO.

More interfaces and factories in the framework pelase.

//Roger
Jan 16, 2009 at 11:14 PM
Roger,

Thanks for the feedback. You are right, the attributed model is not extensible today - however, this by design, or rather through 'lack of design' ;), until we have time to come with a solution that we feel comfortable having customers taking a dependency on it.

However, in saying that, we do have a lower level, called Primitives, that allows customers to build their own programming models from stratch. I'll admit, it can be a little bit of work to get started, however, in the future, likely post v1, we'll be providing something similar to what you are describing (either as an out-of-band release, or as part of v2).

Until then, there are a couple of work arounds:

1) Decorate the attributed primitives that come out of the AssemblyCatalog and TypeCatalog (ie wrap the Definitions coming from the Parts property). This allows you to do simple things such as hide Exports, add/hide additional metadata, manipulate/intercept any Exports before they are set, etc.

2) Write your primitives (ie ComposablePart, ComposablePartDefinition, ComposablePartCatalog, etc) from scratch - unfortunately, today, you don't get the existing functionately that is already available in the attributed model (such as undering properties, fields, types, methods, etc), however, with a bit of luck, we'll see some open-source 3rd party programming models spring up.

As a side-issue, any reason you prefer using a manifest (ie XML) separate from your extensibility points, as opposed to using attributes?

Regards

David
Jan 20, 2009 at 7:24 PM
Hi,

Roger is a friend of mine so he's already aware of this. I'm working on a custom model for MEF at the moment. I'm currently working on getting 100% compliance with the features that the attributed model adds ontop of MEF. On top of that I' adding an open ended definition system, meaning the ability to add custom definition provderis, i.e ways of telling MEF about imports and exports. Currently I have the capabilities of using a config file to define imports and exports

<mef.configuration>
   <parts>
      <part type="...">
         <exports>
            <export member="..." contract="..." />
        </export>
      </part>
   </parts>
</mef.configuration>

And so on. I also have the ability to define them using a fluent interface

FluentDefinitionProvider provider =
   new FluentDefinitionProvider();

provider
   .Import(typeof(...))
   .WithContract(....)
   .AllowDefaults(true)

and so on

I'm currently cleaning up the code and doing a small code review.
Jan 21, 2009 at 1:45 AM
Nice! Looking forward to it.