0

I'm trying to design the architecture for a new LOB MVVM project utilising Caliburn Micro and nHibernate and am now at the point of looking into DI and IOC.

A lot of the examples for bootstrapping Caliburn Micro use MEF as the DI\IOC mechanism.

What I'm struggling with is that MEF seems to by reasonably popular but the idea of the Mef [Imports] annotations smells to me like another flavour of a Service Locator?

Am I missing something about MEF whereby almost all the examples I've seen are not using it correctly or have I completely not understood something about how it's used whereby it side steps the whole service locator issues?

Adam Hardy
  • 377
  • 3
  • 9
  • Ok, so I have just learned about the [ImportingConstructor] attribute that would enable "proper" constructor based DI. But the question still stands, is MEF+[Imports] = Service Locator = Antipattern? – Adam Hardy Jun 22 '12 at 01:05

2 Answers2

3

MEF is not a Service Locator, on it's own. It can be used to implement a Service Locator (CompositionInitializer in the Silverlight version is effectively a Service Locator built into MEF), but it can also do dependency injection directly.

While the attributes may "smell" to you, they alone don't cause this to be a service locator, as you can use [ImportingConstructor] to inject data at creation time.

Note that the attributes are actually not the only way to use MEF - it can also work via direct registration or convention based registration instead (which is supported in the CodePlex drops and .NET 4.5).

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Yes, I understand it's not a Service locator by itself (the heading probably doesn't describe my intention properly), it's just that I'm currently trying to get accross it and all the examples I'm finding to date mostly use [Import] and [Export] and are pretty simplistic. Substitute the [Import] with Singlton IOC.Resolve() in those examples and that's Service locator in my book. Thanks for the comments Reed, you've given me some more reading to do. – Adam Hardy Jun 22 '12 at 03:08
1

I suppose if you were to just new up parts that had property imports and try to use them, then you could run into some of the same problems described here: Service Locator is an Anti-Pattern

But in practice you get your parts from the container, and if you use [Import] without the additional allowDefault property, then the part is required and the container will blow up on you if you ask for the part doing the import. It will blow up at runtime, yes, but unlike a run of the mill service-locator, its fairly straightforward to do static analysis of your MEF container using a test framework. I've written about it a couple times here and here.

It hasn't been a problem for me in practice, for a couple of reasons:

  1. I get my parts from the container.
  2. I use composition tests.
  3. I'm writing applications, not framework code.
Jim Counts
  • 12,535
  • 9
  • 45
  • 63
  • Hey Jim, thanks for your input. I starting to get the feeling that I won't fully grasp MEF as an architectural tool until I jump in a get some coding done. To illustrate my current lack of understanding, your comments above sound to me like: To solve the IOC\Decoupling problem, we used MEF which solved those issues but caused composition problems so complex a whole testing framework needed to be implemented to solve them. – Adam Hardy Jun 22 '12 at 03:16
  • Not really. When getting started, the tests help you learn how everything works. After you know how everything works, its more about catching bone headed mistakes. If it were true that the presence of a test framework implies that a system is too complex, then what does that say about any system which has tests? Anyway, I say go ahead and try it, or try something else. MEF wasn't the first composition framework I tried, but it is my current favorite. – Jim Counts Jun 22 '12 at 04:01
  • All true comments, Thanks Jim. I'll be jumping in soon. – Adam Hardy Jun 22 '12 at 06:11