An Introduction to MEF

Have you ever attempted to write an extensible application?  You know the kind. The applications where your boss wants to be able to add stuff to it without rewriting the entire application and with minimum costs.  Or the type of application you want to release out to the community and provide a way for them to add their own customizations to it.  We have all seen these types of applications; however, if you have ever attempted to write such, it is usually a pain to developer the core application or a pain to develop the extensions or plug-ins.  Thankfully the Managed Extensibility Framework (MEF) is available to those of us that have extensibility needs inside of the application.

Origins and Model

MEF was developed from an initiative within Microsoft in order to simply the creation of building extensible applications.  Developed by Glenn Block and others, the team developed a framework that handled the discovery and composition of the plug-ins/parts to make application extensibility easy to pickup and utilize.  In MEF, a model was developed where decorated parts, containing the extensions of the application, are discovered through catalogs and then composed within a composition container.  What is nice about this model is that it allows for composition at many levels so parts or extensions can include the ability to be extended in addition to extending an application itself (i.e. plug-ins for plug-ins).

How Does MEF Differ From IoC Containers?

During an interview on Hanselminutes episode 148 (Jan 28th, 2009), Scott Hanselman asks Glenn Block how MEF differs from IoC containers.  Glenn provided a very clear (to me) definition of the difference by saying...

You use MEF to manage a set of unknown things. You use IoC containers to manage a set of known things.

Looking at the quote, Glenn makes a good point in that when developers use an IoC container, they typically know of the various types and dependencies they are wiring up through an IoC container.  Sometimes this is configuration based to address differences between environments or just dependencies inside of the code in general. However, when you look at building an application that will allow 3rd party extensions, there's no way of knowing what will be added on.  Now MEF can act like an IoC container but to truly think of it in only that light really places mental limitations on what it can accomplish.

Writing the Hello World

When I started learning MEF, changes had been done since a number of the examples available online were created.  Since we're just getting familiar with MEF in this post, below is a very simple example where MEF is used similarly to an IoC container within a console application.  We'll take this example and greatly expand on it in the next couple of posts; however, for now, I want to just demonstrate the absolute basics to MEF. Before we dive into the code, we need to download the MEF assembly so that we can reference it in our application.

To get the necessary components for integrating MEF into our application, we need to head out to the MEF Project out at Codeplex and click on the Downloads section.  In this series, we'll be focused on MEF Preview (Beta 2) which is compatible with .Net v3.5. In the Downloads section, there should be a link for MEF_Beta_2.zip.  Download and unzip this file.  In the bin directory, you'll want to copy the System.ComponentModel.Composition.dll file.  This is the assembly used to harness the power of MEF.

Now that we have the assembly downloaded, we can create a new console application and reference it. In this demonstration, our simple console application will just output a message.  Very simple, very impractical really but we'll add more practicality over the next posts.  Our console application will need 2 classes; Program.cs and SimpleMessage.cs (shown below)

Program.cs

   1:  using System;

   2:  using System.ComponentModel.Composition;

   3:  using System.ComponentModel.Composition.Hosting;

   4:  using System.Reflection;

   5:   

   6:  namespace MEFExample1

   7:  {

   8:      class Program

   9:      {

  10:          [Import()]

  11:          string Message { get; set; }

  12:   

  13:          static void Main(string[] args)

  14:          {

  15:              Program p = new Program();

  16:              p.Run();

  17:          }

  18:   

  19:          void Run()

  20:          {

  21:              Compose();

  22:              Console.WriteLine(Message);

  23:              Console.ReadKey();

  24:          }

  25:   

  26:          private void Compose()

  27:          {

  28:              var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());

  29:              var container = new CompositionContainer(catalog);

  30:              container.ComposeParts(this);

  31:          }

  32:      }

  33:  }

SimpleMessage.cs

   1:  using System.ComponentModel.Composition;

   2:   

   3:  namespace MEFExample1

   4:  {

   5:      class SimpleMessage        

   6:      {

   7:          [Export()]

   8:          string MyMessage

   9:          {

  10:              get { return "Hello, Extensible World"; }

  11:          }

  12:      }

  13:  }

There's 3 things here we need to look at.  The Program class contains a string property called Message which is decorated with the [Import()] attribute.  This attribute tells MEF that it is an entry point for extensibility.  The 2nd thing to take note of is that our SimpleMessage class contains a string property called MyMessage and returns the message we want to output to the console window.  This property is decorated with the [Export()] attribute which informs MEF that it can be mapped to an [Import()] member of another type.  Lastly, there are the following 3 lines in our Program class's Compose() method...

   1:  var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());

   2:  var container = new CompositionContainer(catalog);

   3:  container.ComposeParts(this);

These 3 lines are used by MEF to discover what parts are available in the current assembly to be imported and compose the parts into the appropriate instance that is extensible (in this case our instance of the Program class).  When we run the project, we see that our message is displayed in the console window without manually mapping SimpleMessage.MyMessage to Program.Message.

This is just a very quick and simple taste of what MEF can do.  In the following posts, we'll dive deeper into declaring Imports and Exports to ensure there not any conflicts during the mapping process as well as demonstrate some options we have on looking for parts outside of our current assembly by using different catalogs.  Until then, please feel free to check out the source code and links located at the bottom of this article for more information on MEF.

Other Resources

• Post Sample Project
• MEF on Codeplex
• MEF On Hanselminutes
• Series Table of Contents

Iowa Code Camp: Session Overview

The Iowa Code Camp was held on  November 7th, 2009 in Des Moines, IA.  With a capacity crowd and a lot of great sessions, it ended up being an awesome time with a lot of great presentations and conversations.  Like conference of this type, you never have time to hit all of the sessions you may want to; however, the ones I was able to attend were still awesome.  Below is an overview on each one.

Getting Started With Behavior Driven Development by Lee Brandt

In his presentation, Lee provided a good introduction to the concepts of BDD.  The presentation focused on the origin of BDD, where it fits, and how it's an evolution of TDD from the beginning which helped to truly set the stage.  For those that have done TDD for a bit, it provided a great introduction into bridging the gap between the business case and the code by using tests as a spec.  Through this and Lee's stressing of an Ubiquitous Language as described in various DDD circles, he showed how BDD can be used in order to provide a technique that helps to show the client what the application will do once done as well as a pseudo-burndown chart of what hasn't been finished yet.  I'm definitely looking forward to exploring BDD again in the near future.

Twitter: @LeeBrandt
Blog: http://www.geekswithblogs.net/leesblog/Default.aspx 

Going From 0 to 100 Dollars an Hour with .Net you Didn't Know by Mitchel Sellers

This session was a good session; however, it wasn't as advanced as I was hoping for.  The abstract of the session focused around using advanced features of .net in order to make you more productive; however, I was hoping for some additional tidbits beyond that of the abstract.  The primary items focused on this presentation were new tips and tricks introduced by .Net 3.5 such as Lambdas, Self Containing Properties, and LINQ. All of these items I already knew and have used them in the past which is why I was hoping for a few tidbits beyond such. That being said though it WAS a good session with a lot of good code samples to convey each concept and technology.  I still learned at least one new thing and was reminded about a few other things as well. While it didn't meet my (probably unrealistic) hopes, I cannot deny that Mitchel's presentation definitely educated a number of people who were also in his session that was overfilled.

Twitter: @MitchelSellers
Blog: http://www.MitchelSellers.com 

Open Spaces

I've been to a few open spaces discussion and have came to the conclusion that some will be good, some will be bad, and others will be between or outside of those labels.  The open spaces session at the Iowa Code Camp was an in between session.  The size of the group was smaller and comprised of a diverse set of primary skills which isn't always a bad thing though the topics in discussion didn't flow like I have experienced in other places.  We had a good conversation about how to get the information to the people that don't come to conferences or how to encourage them to come.  We also talked a little bit about MEF, coding war stories, and some of the side effects of completely rewriting/redesigning an externally facing website.  Lastly we talked a little bit about Kanban vs Scrum and the paradox of software estimation.  All in all there was some good things that came up during the conversation; however, part of me was hoping that more people would have been involved in the discussion and the topics would have been more discussion/problem solving based to an extent.

Intro to ASP.Net MVC by Chris Sutton

I've dabbled in ASP.Net MVC and have wanted to learn more about it; however, finding making the time for such is not always easy.  Everything that I've learned about such has either been about the MVC pattern itself, or about other frameworks in general like Rails or Django.  With only a few MVC Videos watched and about 3hrs worth of coding so far, I decided checking out another intro session wouldn't be a bad idea for me.  Chris Sutton did a great job with the presentation.  He explained the MVC pattern very well as well as describing how the ASP.Net MVC framework relates to it and ASP.Net in general.  He showed a couple of the typical demos for this level of session and afterwards answered all of the questions I had about the next step.  All in all it was a very good session and can't wait until I can make time for using such.

Twitter: @ChrisSutton
Blog: http://subjunctive.wordpress.com 

Silverlight for WPF Developers by Kirstin Juhl

In my opinion, none of the last block of sessions really looked appealing to me.  It wasn't the fact that I didn't think any were going to be good, it was just that I wasn't interested in the topics at hand.  I ultimately decided to check out Kirstin's presentation on what WPF Developers would need to know to transition into the Silverlight space.  While I have only dabbled in WPF a little bit, I knew a number of differences and knew the power of XAML was greater in WPF than Silverlight.  The decision to go here was my current adventures in Silverlight and see what I may be able to learn.  All in all, the session was pretty good for the purpose Kirstin was targeting.  She did a good job at explaining the differences as well as provide information on how to share components between Silverlight and WPF applications (something I knew was possible but hadn't seen an example of up to this point).  Good presentation overall.

Twitter: @KirstinJ
Blog: http://www.geekswithblogs.net/Kirstinj/Default.aspx 

Overall:

Overall, I had a great time at the Iowa Code Camp.  For being a free conference, the presentations, facilities, and of course the prizes were all top notch.  It was a great conference with some amazingly talented speakers and attendees.  All in all I can't wait to head to the next one in the April/May/June timeframe.  Hopefully some of the presentations I'm working on will be ready by then since I'd love to present one.

Reviewing This Year's Goals (2009)

Back in January, I created this post focusing around what I was hoping to accomplish this year.  I was going through my old posts and stumbled across it.  I figured it would be a good time to look over them once again to gauge my progress along with what else I may have done so far this year.

 

Learn F#:

While I do not claim to be an authority of F# by any means, I do feel comfortable in saying that I learned the bulk of the language and be able to determine where it makes sense to use it.  If time allows, I can see myself using it more and more; however, for right now, I've definitely learned a lot from such and can focus on learning other things.

 

Learn DDD:

This one I am really only about 1/2 done with.  While I have went through the information and can understand the concepts involved, I haven't had a good way of applying such yet.  There's existing applications that could benefit from the practices of DDD; but I haven't pushed myself into applying such on a new project yet.

 

Learn Silverlight 2:

I got sidetracked and ended up procrastinated on this one.  While I wanted to learn SL2, I still was a bit apathetic towards it since SL1 wasn't very impressive to me.  Thankfully, I've seen a lot of what Silverlight 3 can do and am going all out on learning more about it.  Except some posts on Silverlight 3 soon.

 

Other Things:

So what else have I been up to so far this year?  Looking back I have worked on some open source projects (namely my SchemaSpy Task for NAnt and contributing to .Net Migrations over on codeplex).  I've also focused a lot of time on keeping up to date on .Net 3.5 and other technologies that I wasn't able to fully take advantage of at a previous employer.  Lastly, I've really been focusing on TDD and just writing better code in general.  There's always room for improvements but being able to learn from what's being talked about over the past year is what's important.

 

Things on the Horizon...

Learning MEF:

The Microsoft Extensibility Framework (MEF) provides some great opportunities to make very extensible applications.  With a need to make a project extensible, I'm definitely going to be focusing on understanding MEF more.

 

Learning Silverlight 3:

I'm already in the process of working in Silverlight 3 but I have only started to write applications with such.  Just like a person who has finished their first true ASP.Net application, there's always room for improvements and things that one can learn to make things better.  I'm at that stage where there's a lot more I can learn about and I'm all for it since Silverlight 3 is awesome.

 

More SchemaSpy:

My SchemaSpy post earlier this year is one of my highest trafficked posts as well as one that I refer back to all of the time.  I'm planning on answering a few outstanding questions associated with that post and also see what else I can do with the tool to make things easier for everyone.

 

<Unknown> Things:

I always leave myself open to the unknown and unforeseen opportunities.  While November and December are usually swamped for me, I never know when inspiration will hit me and I learn something new.

Reviewing UppercuT - A Build Framework Based On NAnt

Earlier this week I went to the Kansas City .Net User Group meeting where the topic of discussion was UppercuT, a build management framework created by Rob Reynolds. The discussion was pretty good and Rob did a good job at showing a number of demonstrations on how to use the various aspects of UppercuT. All in all, I feel like the presentation got the point across as to the typical why/when/how/etc. questions.

What Is UppercuT?

UppercuT is a build management framework based on NAnt. It was created in order to establish a consistent way to build .Net applications with a minimum amount of configuration while providing areas for extensibility. In addition to just compiling, UppercuT provides a number of options to manage application versioning, automated testing, and code packaging. While it can be extended to include such steps through NAnt, UppercuT doesn't deploy code...it only stages it since every company/project's deployment strategies may be different. One nice thing that UppercuT does do in terms of deployments though is provide you instructions on how to wire it up to CruiseControl.net.

When Should UppercuT Be Used?

UppercuT provides a way for people who have not started to take advantage of automated builds to do so quickly. Because of this, it's best suited for projects that don't have automated build systems integrated into them yet. With some configuration changes, it is possible to integrate with your current scripts; however, changes would need to be made on both side to the point where it would honestly be easier to convert your current scripts to custom steps for UppercuT to take advantage on. If you currently use some build framework like MSBuild or NAnt, I would probably recommend at least checking out UppercuT to see if it's a good fit; however, if you or your company already have some system that works for you in place, it may be better to just keep with what you have.

Where Can I Download and Learn More?

You can find more information on Uppercut by going to it's project website at http://ProjectUppercuT.org. In addition, you can check out Rob's blog over at http://ferventcoder.com/ as well as on Twitter by following @ferventcoder and @ProjectUppercuT.

Is Learning though a UI worth it?

Do you remember the last time you learned a new, back-end technology like Linq-to-Sql, Entity Framework, NHibernate, the Twitter API, or some other 3rd party API? How did you first go about learning it?  If you used some tutorial of some sort (be it a blog, video, or some other medium), how did you try it out?  Did they have create a basic web page to present the data from the API that you were consuming? If you DID create any form or UI to consume this API, here's two questions for you...

 

1. How long did it take you to create that UI compared to writing the code that uses the API?
   
   
2. Did you learn more about the API from the UI or from writing the code that actually interacted with the API?

 

Now, let me restate that I'm aiming these questions specifically at back-end technologies.  Any technology that deals with any aspect of a UI (i.e. JavaScript, Silverlight, etc.) obviously depends on the UI and really does not apply. However, if you're NOT focused on a UI-dependent technology, why do you create a UI to learn something that doesn't require it?

Don't get me wrong.  I was guilty of this as well and what I found is that I got sick and tired and bored spending so much time creating a UI and it would take me longer to get to the subject of my studies.  Throw in a dash of OCD or ADHD because I couldn't just make a simple UI but needed some form of basic layout and color contrasts at the very least and it was a recipe of boredom.  It wasn't really until something clicked that I began to really realize that I learned more from the tests or the debugger while stepping through the code consuming these APIs than how the information was presented.  Sure it felt good when I could apply what I learned to a UI but applying the UI layer did not directly provide any value for me towards learning the API.

But again, if it takes so much time and provides a greater opportunity for distractions, is it worth it to learn a back end process by means of applying such to a UI?

My Barriers to Learning TDD

As a follow up to my previous post declaring that I finally "get" TDD to some extent, I figured I'd reflect on the barriers that I have had up to this point which made it difficult for me to learn how to unit test in some effective manner as well as truly understanding the benefits of TDD practices.  Now, I am by no means claiming to be an expert in unit testing, mocking, or TDD.  I didn't open the refrigerator, drink some of the TDD-flavored Kool-Aid, and threw on a subsequent Mortarboard to illustrate that I've somehow graduated into this new, higher level of software development.  I'm still learning from others as well as my own errors experiences just like everyone else.  The purpose of this is to reveal to others some of the issues that I had and hopefully provide some insight on how to overcome such.

 

The Examples Are Too Simple

This barrier was by far the most difficult for me to overcome.  I would read up on all of the buzz about how to add unit tests to your code and how to apply unit testing into TDD.  I would follow the examples and understand it and be fine; however, I would always stall out whenever I tried to do it in a real world scenario. One day, I got extremely frustrated trying to fit all of this this together even if it looked like a square peg for a round hole to me at that time.  I began to wonder how unit testing in general would work on such complex real world objects and that's when it hit me.  Around this same time, I was diving into the S.O.L.I.D. principles of Object Oriented Design and began to count the dependencies I had in the code.  The more I broke out the code into less complex objects that followed the principles, the easier it was for me to map the unit test examples that previously were "too simple" to my code.  The barrier wasn't so much that the examples were too simple as it was that my code that I was trying to directly apply the lesson to were too complex.  On the last project I had, I didn't apply unit testing to it; however, I tried to adhere to the S.O.L.I.D. principles as much as possible.  When I was trying to retrofit the tests into it, I was able to do it as well as find places where I didn't follow the S.O.L.I.D. principles as much as I thought I did.  Looking back, I probably wouldn't have had any of the refactoring issues I had after the fact if I had used TDD to provide a test-first basis for the object designs.

 

But...This Class Uses the Database

This was another barrier for me that partially stems from the previous example.  Looking over the majority of Unit Testing and TDD books and blog posts out there, very few of them actually touch dependencies as common as a database.  Looking at my own code at the time, I had repository classes that handled all of the CRUD operations to the database as well as spit out the records as strongly typed collections (where necessary).  How do I test this class when there is such a deep dependency with the database?  I was truly perplexed by this issue and decided to ask the question on StackOverflow.  The responses led me to realize that my class was doing 2 things; calling the database AND transforming the returned data in to a manner I needed.  By pushing the direct database calls to a separate class, I was able to mock away the database and make sure these particular class could be tested.

Now, that only solved half of the issue.  I abstracted the dependency of those classes but I still had data provider classes that still interacted with the database.  This is where I truly learned the difference between Unit Testing and Integration Testing.  With such an outside dependency as a database or a web service, I began to see some examples that created separate, controlled instances of those dependencies in order to test the queries and CRUD functions.  The technique I use now for database integration is to use NHibernate, even if the primary project doesn't use it.  NHibernate has the ability to recreate table schemas for each tests which helps automate the state of the database for each test.  An example of this can be shown over at NHForge.org's How-To section under Your First NHibernate Based Application.  After setting this up, it provides me an easy way to test the barrier of the database.

 

Am I Just Testing the Mocking Framework?

I had a class the called into a 3rd party library that I wanted to test.  I abstracted the 3rd party library into a proxy and called such from my class.  The 3rd party library sent messages over a TCP socket connection and returned back an "OK" or an "ERR" message.  The class that I wanted to test created and sent the messages and then reported on what it got back.  For example, I would call a method in the class and it would send a message "FOO" to the proxy and get back "OK".  That's a little simplified (see barrier #1 above) but the class itself did pretty much that.  When I setup the test, I mocked out the proxy dependency and had it return "OK" whenever my class sent it "FOO".  This is not that meaningful of a test since there is no logic in that 1 method.  Other methods had logic based on the parameters; however, this one method was just this simple.  Was I just testing the mocking framework with this particular test?  Arguably, yes...I was; however, in the future, if that ever had to change, I now have a test that I can use to ensure that I get the information correctly.

 

But Unit Testing = More Code & Time

This wasn't so much a barrier for me mentally but was a barrier to adopt it at work.  From what I've experienced now, writing unit tests AFTER the code has already been written DOES lead to more code being written, more refactoring of existing code to make it testable, and more time to do all of this.  However, I have seen that writing your unit tests BEFORE you write any code (as advocated in TDD), you tend to code at the same speed if not a little faster.  I found that I wrote code faster when I did tests before since the production code was already designed for me through the tests I had just written.  There was less thought at the time of coding since the design was setup while I was writing the tests.  I also found myself near-instantly defaulting into the S.O.L.I.D. principles instead of looking at them sometimes as a refactoring step.  Lastly, I wrote less code that would have been for future use (i.e. YAGNI). 

All of this came with a paradigm shift in my object design style.  While some of the basic directory structure and such was the same, I looked at my classes more at a "how do I want to call this class" as opposed to "what methods do I want to show in this class".  The shift in my thinking was more of a consumer than a provider or retailer.  If you only code what you need, you tend to not code things you don't need.  It's as if you go to the grocery store for 1 item and that's the only item that the store has.  Nothing else to distract you in that point in time.  No other products around that you may need in the future.  You are in that 1 moment in time and in that moment, you only have 1 need as a consumer.

 

Summary

While there were other barriers I came across, the rest were either very minor or more about basic implementation like how to return an IDataReader object. I'm sure that I'll stumble across more barriers and moments of enlightenment the more I practice TDD or just unit testing in general.  Until then, I hope some of the items described and discussed here can help others who have struggled to get their head around unit testing in general and some of the principles of TDD.

Finally Understanding the Merits of TDD

I'm not a TDD person...or at least I wasn't until last week.  Up until then, I had read the blogs and looked at the examples to try to understand TDD and unit testing (with mocking) in general.  Almost all of the examples I was shown demonstrated very basic scenarios that, in most cases, were too trivial to show value.  I would ask people who would speak about unit testing in general how you'd do a specific scenario and would get mix responses ranging from "just try it" to "you should be using this tool and it'll just write the tests for you".

Last week, I had some free time to where I could truly evaluate a code base I finished up with the prior week and see if I could apply some tests to it.  The code I wanted to add tests to were simple repositories where I had abstracted the database calls to separate classes.  Being told to mock the databases out in the past, I started to do that and focus solely on these repositories.  In some instances, it felt like I was testing the abilities of the mocking framework instead of my code but these methods were simple by design (i.e. "Get Customer by Id 'X'").  It was when I started to test more of the methods that I saw that some of the code I wrote had some issues.

The code was functional; however, it wasn't easily testable.  When I would attempt to describe the test, I found that the code did more than one things (breaking the Single Responsibility Principle).  Another incident showed that the name of 1 whole class didn't make sense.  A third incident showed me an issue with the number of complexities that come from multiple dependencies and object inheritance.  After each time that I finished refactoring these issues out of the code and eventually got to working tests, I began to see how the questions that TDD (and BDD) cause you to ask while designing an application really shine.

One example of this was a duplication of code.  I had a class called, for the sake of this post, UserRepository.  The UserRepository had a method to get all users in the system and returned a List<User> back to the calling code.  This class also had a second method that did the same thing but the List<User> only had the FirstName and LastName properties populated.  Why did I write such months ago?  Short answer - I have no idea.  Looking through the code, I found that a different feature needed just the FirstName and LastName properties and nothing else...it was then sending the List<User> to the client for an AJAX call.  While I can understand this now, I could have better implemented the solution by if I looked at the scenario and behavior better initially.

If you ever find yourself wondering how writing more code for TDD or just basic unit tests can actually help the code, my recommendation is to just try it.  Take a simple class that has only a few pieces of logic in it and test it.  Next, take a simple class that has a dependency that you'll need to mock out and test that too.  After you understand how to write these basic types of tests, you can move into the self-reflective questions that really shine in TDD.  Questions like "What type of data do I want to work with when I call method X?", "What will this class need (a.k.a. dependencies) to get me data Y?", and "Is this functionality already present?" are all questions that get forgotten while we're sometimes blindly coding. 

Looking ahead, I can only imagine how my code will be looking.