Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been working with MEF for about 2 weeks. I started thinking about what MEF is for, researching to find out how to use MEF, and finally implementing a Host with 3 modules. The contracts are proving to be easy to grasp and the modules are easily managed.

Although MEF has a very practical use, I am wondering to what extent? I mean, is everyone going to be rewriting existing applications for extensibility?

Yes, that sounds, and is insanely impractical. Rhetorically speaking:

  • how is MEF affecting the current trends in programming?

  • have you begun looking for opportunities to use MEF?

  • have you begun planning a major re-write of an existing app that may benefit from extensibility?

That said, my questions are:
how do I know when I should plan a new project with extensibility?
how will I know if an existing project needs to be re-written for extensibility?

Is anyone using MEF?

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted
+100

Is anyone using MEF?

I'm working on a Silverlight project using the MVVM pattern. We started by just wiring all of the VMs together as necessary through interfaces and manual dependency injection (either constructor or property injection depending on the need). It began to get painful, and we started using MEF as basically a dependency injection framework to export certain services that are used across view models, and import them into the view models that need them. Works perfectly and with very little code.

Yes, there are some purists out there that will say MEF is not intended for dependency injection and a real dependency injection framework will do much better. However, MEF is baked right into .NET which is a big plus, and it was enough to meet our needs.

how do I know when I should plan a new project with extensibility? how will I know if an existing project needs to be re-written for extensibility?

IMO, you should always separate concerns appropriately and use interfaces to allow for different modules to change indepently. If you do this right, then when you find a need for extensibility, MEF should be easy to add in. But I wouldn't start a project that had no extensibility requirements and put MEF in just in case. I would wait for there to be a need. For existing projects, if a need arises, I would evaluate the effort of rewiring the project to use MEF versus alternative solutions versus not doing anything, and see which wins.

share|improve this answer
add comment

Currently I'm using MEF in a few projects that incorporate the Repository pattern.

One is using different repository types while unit testing, the other project is using local (straight to DB), remote (WCF) and testing repositories.

Both projects can change their repository types via code or configuration, and is based on MEF metadata/ Lazy types.

To date, both projects are running incredibly well.

share|improve this answer
add comment

The mistake people make, and I think it's because of the naming (Managed Extensibility Framework) is in assuming MEF is only practical for extensibility. MEF really addresses three key things: extensibility, discovery, and metadata. The last two are very powerful even for an application that will never see a single plug-in or extension.

This is an article I wrote about it's power for discovery as an IOC container: http://www.informit.com/articles/article.aspx?p=1635818

I use MEF in most enterprise line of business applications because it makes it faster and easier to build and maintain modular applications in Silverlight.

share|improve this answer
    
I've read your article -- twice at least ;) –  IAbstract Apr 29 '11 at 19:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.