Object instantiation - scattered code

Dec 31, 2008 at 2:12 PM
Edited Dec 31, 2008 at 2:36 PM
Hi,

I'm currently playing around with MEF and trying to integrate my own AOP framework NAspect with MEF.

But as far as I can tell, the object instantiation is not pluggable / extendable , it is hardcoded into the "ReflectionComposablePart.cs":

instance = this.Definition.Constructor.Invoke(arguments.ToArray());

There is currently no abstraction going on over the instantiation, just a call to ctor.invoke.

In order for someone to alter how objects are created, they have to change this code.
And I'm not talking about how they are configured, I'm talking only about how they are instanced.
It would be much much cleaner if there was a factory for this that _all_ ComposableParts could utilize, so that there is a single point where the raw objects are created.
This way, one could change the behaviour of the factory and make it instance objects through other 3rd party frameworks that might want to subclass or do other tricks to the yet to be created object.

The current approach prevents me from instantiating my own runtime emitted subclasses instead of the original types.

(I'm well aware that I could "wrap" the objects in wrapper proxies, but that comes with a whole load of other issues and would be more of a workaround due to the lack of extensibillity on this part in MEF)

So is there any chance that you will introduce an ObjectFactory class that all the ComposableParts will use ?
(instead of scattering ctor.invoke and Activator.CreateInstance all over the framework)

//Roger

Dec 31, 2008 at 6:03 PM
Hi Roger

Thank you for the feedback. We are looking into options for supporting custom activation. Currently the model is not designed to support this. Today, you do have the option of creating a custom programming model by implementing your own Composable Part, Composable Part Definition, Export Definition, etc. It's not a simple task, but doable. This post gives an overview of what is involved http://weblogs.asp.net/mhawley/archive/2008/11/28/mef-factories.aspx.

Regards
Glenn
Jan 1, 2009 at 10:20 AM
Hi,

I understand that I can plug my own model into MEF, but forcing the users to extend by _re-writing_ the entire portion they want to extend is not very user friendly.

I know that MEF was/is leaning more towards a plugin framework than a standard DI container.
And as a plugin framework it works great, you can add _new_ stuff to it w/o problems.

But once you try to alter/extend the behavior of the _existing_ pieces things get really awkward.

And maybe it's not the intention of MEF to support this.
But a framework who's main concern is to deal with dependency resolution and coupling of components, it would be sad to see that the framework itself didn't support loose coupling between its own parts.

I might come out as a pessimistic whiner here, but I really do think that MEF is a great project and that it has some brilliant features such as the runtime recomposition of objects.
If you just make it possible to extend the framework itself some more, we could adapt MEF ourselves to support the same things that standard DI frameworks do.
And we would see an entire eco system of MEF extensions in the future instead of forcing us to use MEF together with a trillion of other frameworks in some more ore less compatible way.

//Roger



Jan 2, 2009 at 5:24 AM
Hi Roggan

Authoring your own model is not completely starting from scratch.as it is inheriting from our abstract classes and then putting in your specific implementation. It is quite a bit of code though.

I understand your concern and really appreciate the feedback. We had a specific set of goals in V1, which included supporting the attributed model and decoupling MEF from a specific model (although we ship a default). Thiis an uber extensibility point, in that you can design a model that meets your needs. Supporting AOP / Custom activication however was not one of our goals for the attributed model as it was not needed for the scenarios we were trying to support in V1. We're not blocking people for using MEF to do AOP, because of the alternative model support. We have additional extensibility points in the container, for example our new Export Provider allows you to customize the container at a very fine-grained level. You could even potentially implement AOP functionality at this layer (without authoring an entire new model), but it would require a bunch of work, which depending on how you did it might be very hacky :-)

I cant promise that we will get support for AOP in V1, I can promise you that we are listening and we will put it on our prioritization queue.

Thanks
Glenn
________________________________________
From: Roggan [email removed]
Sent: Thursday, January 01, 2009 3:21 AM
To: Glenn Block
Subject: Re: Object instantiation - scattered code [MEF:43244]

From: Roggan

Hi,

I understand that I can plug my own model into MEF, but forcing the users to extend by _re-writing_ the entire portion they want to extend is not very user friendly.

I know that MEF was/is leaning more towards a plugin framework than a standard DI container.
And as a plugin framework it works great, you can add _new_ stuff to it w/o problems.

But once you try to alter/extend the behavior of the _existing_ pieces things get really awkward.

And maybe it's not the intention of MEF to support this.
But a framework who's main concern is to deal with dependency resolution and coupling of components, it would be sad to see that the framework itself didn't support loose coupling between its own parts.

I might come out as a pessimistic whiner here, but I really do think that MEF is a great project and that it has some brilliant features such as the runtime recomposition of objects.
If you just make it possible to extend the framework itself some more, we could adapt MEF ourselves to support the same things that standard DI frameworks do.
And we would see an entire eco system of MEF extensions in the future instead of forcing us to use MEF together with a trillion of other frameworks in some more ore less compatible way.

//Roger




Read the full discussion online<http://www.codeplex.com/MEF/Thread/View.aspx?ThreadId=43244&ANCHOR#Post143843>.

To add a post to this discussion, reply to this email ([email removed]<mailto:[email removed]?subject=[MEF:43244]>)

To start a new discussion for this project, email [email removed]<mailto:[email removed]>

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings<http://www.codeplex.com/site/discussions/project/unsubscribe/MEF> on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com
Oct 28, 2010 at 8:31 PM

Hi Glenn,

I am fairly new to MEF, but for what I've seen and learned so far: my deepest respect, this is a very nice piece of ingenuity!

I stumbled upon the same issue as Roggan (custom activation) - will it be addressed in version 2?
What I would really like to do is to provide a custom activation mechanism (dynamic proxy) but only for certain types.... It would be great to have the opportunity to decide whethere I want to augment/change the activation on a case by case basis somehow (depending on the Type).

As far as i understand it, an ExportProvider would not be sufficient for me - because my proxied viewmodels (want to do automatic INotifyPropertyChanged) should also be able to have standard [Import]s.

If version 2 does not support the approach... are there any good resources regarding that matter?

Thanks,
Wolfgang

Oct 28, 2010 at 10:19 PM

Hi Wolfgang,

besides INotifyPropertyChanged, is there any other use case for custom activation in MEF?

Thanks

Oct 31, 2010 at 8:26 AM

Hi haveriss,

I would say that it would be useful in any case where you need or want more control over the instantiation.. Maybe setting a property manually after creation (similar to SourceProvider) or simply to use a proxy.... not only for INotifyPropertyChanged but also for any type of AOP.

It's probably not among core requirements for MEF but on the other hand it would be very nice to not only use MEF for composition (and an additional second "IoC-Thing" for all other DI-Requirements) but simply just use MEF and have everything covered.... (especially lifetime management and activation needs)

Kind regards,
Wolfgang

Nov 1, 2010 at 7:47 PM

You may want to add your votes to http://mef.uservoice.com/forums/75901-general

Nov 2, 2010 at 8:36 AM

Good idea :-) Thanks for the link!