Agilification

A friend asked me for help getting started with StructureMap. I thought it might help someone else, so here it is in all of its simplicity.  Please let me know if this helps you or if you have anything to add.

--------------------------------

using StructureMap;
using StructureMap.Configuration.DSL;

public class Bootstrapper
{
    public void Bootstrap()
    {
        ObjectFactory.Initialize(init =>
        {
            init.Scan(scan =>
                {
                    scan.AssembliesFromApplicationBaseDirectory();
                    scan.WithDefaultConventions();
                }
        }
    }
}

You can pass a predicate to "AssembliesFromApplicationBaseDirectory" to restrict it to only scan assemblies that match a rule you specify ( in case you want to only scan your assemblies, and not any referenced assemblies you may be working with - very handy).

You can also do things like "scan.AssemblyContainingType<MYTYPE>();" where MYTYPE is a type in an assembly in which you want to scan for services/dependencies.

The call to "WithDefaultConventions()" tells StructureMap to wire up interfaces like "IFooService" with concrete implementations like "FooService".

If you need to change things you can add initialization expressions in the init section:

init.For<IMyService>().Use<MyReplacementService>();

There's a lot more to it, but this is a good start.

Tags: s.o.l.i.d., ioc, structuremap

Last week I wrote about my need for Dependency Injection for the Compact Framework.  Many DI frameworks do not support the Compact Framework, so I identified four options:

1. Don't use IoC and dependency injection
2. Continue to "roll-my-own" dependency injection tool
3. Pray that Jeremy Miller ports StructureMap to the Compact Framework
4. Use Ninject

Well, there is a fifth option that I hadn't considered: finding an open source project that does what I need.  Germán Schuager pointed me to a project he created on Google Code called Compact Container. It is lightweight, clean and simple.  After reviewing Germán's code, I found that it would support most of my needs, short of a couple of nice-to-have features.

1. Marking the injectable constructor with an attribute
2. Setting a default object life cycle for a container (rather than having to pass in the life cycle every time a type is registered with the container)
3. Ability to resolve concrete types that have not yet been registered with the container

In the spirit of open-source, I created the necessary code and sent it back to Germán for inclusion in the project.  As of this posting, he's included the constructor attribution feature in the source repository, and hopefully he'll also add the other features as well.

My struggle with Ninject came down to the fact that it operates in a fashion quite distinct from other DI frameworks. I must admit that the Ninject DSL is quite appealing, but certain things that I'm comfortable doing with StructureMap are difficult if not impossible to attain using Ninject without creating a bunch of direct dependencies on the Ninject assemblies.  So it looks like Compact Container is the winner at this point.  We'll see if it sticks.

 

Tags: agile, ioc, s.o.l.i.d., compact framework, dependency injection

I've spent the last 2 years developing WinForms and ASP.Net MVC applications, so it's been a while since I've worked on a .NET Compact Framework project.  In case you haven't heard of it, the .NET Compact Framework is a compact sub-set of the .NET framework that can run on devices with limited resources (like phones, blackberries, barcode scanners, etc.).  As I began working on the project, I decided up front that I would use the same SOLID principles I use on any other application.  I almost hit a roadblock, however, when it came to choosing a Dependency Injection framework.

I began with just a simple roll-your-own dependency resolver.  But this solution doesn't work well once you need to inject multiple layers of dependencies and build up your object hierarchies in a more complex fashion.  So I did some research into which (if any) DI frameworks support the Compact Framework.  It turns out that only one DI framework supports the Compact Framework: Ninject.  Typically StructureMap has been my DI container of choice, and recently I've spent some time evaluating the Unity container from Microsoft, but neither of these support the Compact Framework.  So I guess I've got a limited number of choices:

1. Don't use IoC and dependency injection
2. Continue to "roll-my-own" dependency injection tool
3. Pray that Jeremy Miller ports StructureMap to the Compact Framework
4. Use Ninject

Option 1 is not even a real option.  There are too many benefits to be gained from loose coupling and depending on abstractions rather than details.  Option 2 seemed feasible at first, until I needed more complicated object hierarchies.  I can't hold my breath and wait on something that may never happen, so Option 3 isn't a real option either.  So, it looks like I'm going to be heading to Ninja school!  I'll let you know how it goes and what I discover along the way.

Tags: agile, ioc, s.o.l.i.d., compact framework, dependency injection

Debates around inversion of control containers (IoC) have a tendency to turn for the worst very quickly.  While there are common goals of loose coupling, improved testability and greater cohesion, often it seems that a lot of effort is spent debating about choices regarding which IoC container to use.  The debates grow especially intense when a framework is created with a dependency on a particular container.

A couple of months ago, Jeremy Miller suggested the creation of a common library so that developers could allow consumers of their frameworks to plug in the IoC container of their choice (It's time for IoC Container Detente).

After a few short weeks, the Common Service Locator project was born.  This project provides a simple adapter and static gateway for registering the IoC container of your choice into a framework that leverages the Common Service Locator.  I created a StructureMap Adapter for this project that you can download on CodePlex.  For simple, in-house applications over which you have complete control, there may not be a need for such an adaptation.  But there are times when swapping out different container implementations is useful, so it's nice to know that it's there when you need it.

Tags: ioc, s.o.l.i.d.

Last week, Derick Bailey presented at the Austin .NET User Group meeting.  He's posted his slides and sample code from the presentation and it's well worth the time to review.  Derick does a spectacular job laying out the specifics of SOLID object oriented design principles.

• S (Separation of Concerns)
  
• O (Open/Closed Principle)
  
• L (Liskov Substitution Principle)
  
• I (Interface Segregation Principle)
  
• D (Dependency Inversion Princple)
  

The power of Derick's approach is that he starts with a simple solution and then refactors to patterns, rather than simply showing off a completed application with heavy use of design patterns.  This is a good reminder that design patterns aren't a good thing in-and-of-themselves.  In fact, unneccesary use of patterns is a code smell--if all you need is a simple solution, then create a simple solution!  But as requirements change and become more complicated, it is vital to have the knowledge for how to modify your application to accomodate the necessary changes.  Derick's presentation will help you understand the principles and patterns that will enable you to face changing requirements with confidence.

Tags: s.o.l.i.d., ioc, oop