# Friday, 17 December 2010

As I have stated in previous posts I am huge supporter of TDD and you can’t get too far doing true TDD before you are forced to introduce an IoC Container, also known as a Dependency Injection Container.  You can find out more about Inversion of Control and Dependency Injection here.  When I first started looking into using the concept of Inversion Of Control in my code, my first stop was StructureMap.  Why…I can’t really remember but it was the first IoC framework I tried and it is the one I currently prefer to use.  But, being a consultant I pride myself in knowing my options and being able to work with or recommend the tool that is best suited for the situation…hence this blog post and example code.  I decided to put together this post and code showing how, if you plan accordingly, you can swap out any of the *major* IoC Frameworks without impacting the code. 

I set out with the goal of creating a swappable solution that would allow me work with the following IoC Frameworks.

Side Note:  Using NuGet really makes pulling down tools/packages very easy.  Check It Out!

So, let’s get started!  The basic principals of setting up and using an IoC container in code are the same no matter what Container you are using.  From the 30,000 foot view you need to:

  1. Map what concrete class implementations to use for what abstract (interface, abstract class) implementations.
  2. Have some way of resolving to a concrete implementation when passed an abstract implementation.

To get the juices flowing here is how you tackle this in StructureMap.

  1. Create a class that will be called on when our app spins up that will take care of our abstract –> concrete mappings.  Typically this class is called a Bootstrapper.  As you can see this class contains when method called Bootstrap that performs the mapping.  In this example there is one mapping that says (see line 18) whenever you need a concrete instance of IMyBusinessClass use the MyBusinessClass class.
    StructureMapBootsrapper
    1. using ChoosingAnIoC.Business;
    2. using ChoosingAnIoC.Core.Interfaces.Business;
    3. using StructureMap;
    4.  
    5. namespace ChoosingAnIoC.App.Bootsrappers {
    6.  
    7.     /// <summary>
    8.     /// Maps Abstract to Concrete Implementations Using StructureMap
    9.     /// </summary>
    10.     public class StructureMapBootstrapper : IBootstrapper {
    11.  
    12.         #region IBootstrapper Members
    13.  
    14.         /// <summary>
    15.         /// Setup of mappings
    16.         /// </summary>
    17.         public void Bootstrap() {
    18.             ObjectFactory.Initialize(x => x.For<IMyBusinessClass>().Use<MyBusinessClass>());
    19.         }
    20.  
    21.         #endregion
    22.     }
    23. }

 

  1. Create a class that can use the IoC containers mappings to hand you a concrete instance of class on demand.  I call this class a Resolver.
    StructureMapDependencyResolver
    1. using ChoosingAnIoC.Core.Interfaces;
    2. using StructureMap;
    3.  
    4. namespace ChoosingAnIoC.Core.DependencyResolvers
    5. {
    6.     /// <summary>
    7.     /// Class for resolving dependency's using StructureMap
    8.     /// </summary>
    9.     public class StructureMapDependencyResolver : IDependencyResolver
    10.     {
    11.         /// <summary>
    12.         /// Returns a concrete instance of the
    13.         /// supplied Interface
    14.         /// </summary>
    15.         /// <typeparam name="T">Interface of concrete instance to return</typeparam>
    16.         /// <returns>Concrete instance of the supplied interface</returns>
    17.         public T GetConcreteInstanceOf<T>() {
    18.             return ObjectFactory.GetInstance<T>();
    19.         }
    20.     }
    21. }

If  we add enough level of abstraction at these two points we can swap out any of the current IoC containers and hopefully be able to handle any that come along in the future.  As you probably noticed in the two code examples above…both of these classes implement an interface.  Below is the code for the two interfaces.

      IBootsrapper
      1. namespace ChoosingAnIoC.App.Bootsrappers {
      2.  
      3.     /// <summary>
      4.     /// Bootsrapper Interface
      5.     /// </summary>
      6.     public interface IBootstrapper {
      7.  
      8.         /// <summary>
      9.         /// Bootstrap and perform mappings
      10.         /// </summary>
      11.         void Bootstrap();
      12.     }
      13. }
      IDependencyResolver
      1. namespace ChoosingAnIoC.Core.Interfaces {
      2.  
      3.     /// <summary>
      4.     /// Interface for implementations of Dependency Resolver
      5.     /// <remarks>
      6.     /// This interface adds a layer of abstraction when we
      7.     /// resolve dependencies.  It will allow us to swap out
      8.     /// out IoC framework with minimal impact on our code.
      9.     /// </remarks>
      10.     /// </summary>
      11.     public interface IDependencyResolver {
      12.         
      13.         /// <summary>
      14.         /// Returns a concrete instance of the
      15.         /// supplied Interface
      16.         /// </summary>
      17.         /// <typeparam name="T">Interface of concrete instance to return</typeparam>
      18.         /// <returns>Concrete instance of the supplied interface</returns>
      19.         T GetConcreteInstanceOf<T>();
      20.  
      21.     }
      22. }

                                    Use this code a couple of factory classes to return whatever Bootstrapper and DependencyResolver our application is configured to use we can swap out IoC containers without affecting our code.

                                    The complete code including implementations of all the IoC containers noted above can be found here!

                                    posted on Friday, 17 December 2010 11:06:46 (Central Standard Time, UTC-06:00)  #    Comments [3]
                                    # Sunday, 14 November 2010

                                    I have done a couple of presentations lately on IronRuby and I am now making the slides and demo code available.  Enjoy!

                                    IronRubyAndYou

                                    posted on Sunday, 14 November 2010 18:54:00 (Central Standard Time, UTC-06:00)  #    Comments [2]
                                    # Friday, 22 October 2010

                                    At my current client I was tasked with implementing coding standards and styles and developing a process so the configurations can be easily maintained and shared.  ReSharper was already in place at the client and the since 99% of what they wanted to enforce, initially at least, was style related I chose to combine ReSharper with StyleCop.

                                    After looking around the interwebs for awhile I realized this process is either impossible or undocumented…or both.

                                    The process I came up with is about 90% of what I was hoping and still requires two manual steps by the developer but overall it is solid.  So, let’s get started.  First download and install the following tools:

                                    1. StyleCop 
                                    2. StyleCop+

                                    Although StyleCop+ is technically not required it does a great job with allowing you to extend and customize a lot of the built in StyleCop rules.  So I certainly recommend it.

                                    The trick with StyleCop is that it will continue to look up the code tree for settings files and keep adding them together and then adds the settings file from StyleCop install directory to top things off.  That is unless you tell it to do otherwise.  What where going to do is first place a Settings.StyleCop file where all devlopers can access it.  Next we are going to place another at the root of our code directory.  So if your code resides at C:\Dev\Code then place the Settings.StyleCop file there.  We can then open up the settings file we placed out on the network that everyone has access to and tell it not to merge with any other settings file.  This will be the official settings file.

                                    image

                                    Next we will open the settings file in the root of our source tree and tell it merge only with the settings in the shared location.

                                    image

                                    Now once you make changes at the shared level they will be merged with each developers settings file.

                                    Next we can deal with ReSharper…Stay Tuned!

                                    posted on Friday, 22 October 2010 16:19:52 (Central Daylight Time, UTC-05:00)  #    Comments [9]
                                    # Thursday, 23 September 2010

                                    On this, my final day at my current employer, I have mixed emotions.

                                    1. Excitement – I am very excited to become a part of the Skyline Technologies family.  I feel that they certainly have the most to offer at this point in my career.
                                    2. Disappointment – I am disappointed that my vision of the future and my current employer’s vision could not align.
                                    3. Confusion – This is the emotion I am having the most difficulty with.  It all comes from when I asked myself “What did I gain from working for my current employer for the last 5 years?”  The first things that come to mind are experience and knowledge.  But does this have anything to do with my current employer?  As a consultant, to be completely honest, all my current employer did was arrange for the client and myself to speak.

                                     

                                    I am going to stop there.  I don’t want to dwell in the past.  All I can say is that in the last 5 years I have grown more than I had in the previous 5 years and what more can you ask for.

                                    Here is to the next 5 years….

                                    posted on Thursday, 23 September 2010 08:54:19 (Central Daylight Time, UTC-05:00)  #    Comments [0]
                                    # Friday, 17 September 2010

                                    Earlier this week I got into a bit of spat with a couple of Tweeps on Twitter.  It started with someone I follow and respect re-tweeting something someone tweeted about him which basically said the tools which he is associated with aid developers in creating bad design.  I responded to this tweet in support of this person whom I respect by saying…

                                    Tools don’t do bad design.  Bad developers do bad design.

                                    Immediately after tweeting this I got multiple reply’s stating that just because you do bad design or write bad code you are not necessarily a bad developer. 

                                    To be blunt…this confused the hell out of me.  If you knowingly create a bad design or write bad code how can you be a good developer?  I guess the key word in that previous statement is *knowingly*.  But if you don’t know what good design/code is in my book you can’t be a good developer.

                                    Don’t get me wrong.  We have all been in the position when due to forces outside of our control we have been forced to write imperfect code or create a less than perfect design.  To me this is one place where you can quantifiably determine the good developer from the bad developer.  A good developer, when writing imperfect code due to factors outside of there control, will do one or more of the following:

                                    1. Get upset because they know they are writing less than perfect code/design.
                                    2. Leave a comment stating why the code/design was done in this factor.
                                    3. Add a ToDo for refactoring later.
                                    4. Will do the imperfect code/design in such a way that the refactoring effort will require less effort.

                                    This argument of writing bad code does not a bad developer make really rattles me.  That is exactly what it does!

                                    OK…Let me have it!

                                    posted on Friday, 17 September 2010 08:58:51 (Central Daylight Time, UTC-05:00)  #    Comments [1]