Part of a project I’m working on, has strong extensibility requirements, so for last two days I’ve been working on a proof of concept prototype for it, using MEF.
Not only do we need plug-ins, but also there will be at least two client applications using them (one in WPF, and the other one in Silverlight), so we decided to decouple the view of the plug-in from the logic behind it using something along the lines of MVP (Presenter First would be the closest).
That is where I hit the wall. I decorated my classes and interfaces with appropriate Import and Export attributes, to tell MEF how I want it to inject my dependencies, just as if it was a regular dependency injection framework. The problem is, it isn’t, and it took me a while to let this thought drill down into my mind.
I mean – I knew that it’s now, I’ve read the introduction, and even Ayende’s post, but subconsciously I kept thinking of it in terms of resolving dependencies. This was not allowing me to think outside the box, when I hit the wall.
The situation looked like on the picture: I had a shell that contained the collection of View parts (WPF UserControls for WPF client actually, but I’ll refer to it as IShellView) that were the V in my MVP triad. The shell was built up by MEF, and MEF injected the View instance as required. This was however far from what I wanted it to do, because it created only the view, because this was all the Shell (explicitly) needed. This is logical of course, not that it was any consolation for me.
The problem was, as you may have guessed by now, in my wrong approach towards MEF. I was looking along the lines of ISubDependencyResolver, but since it’s not a DI nor IoC framework, there wasn’t any.
When I finally acknowledged it aloud (while talking to a colleague) I created a working solution in a matter of minutes, using field Export, something that no Dependency Injection framework would allow you to do. While maybe not an ideal solution – it works and finally helped me overcome the MEF-as-DI-framework subconscious mindset.