Marcus The Blog (by MarcusTheBold)

A philosophical discussion about Inversion of Control frameworks

2010-01-10T21:19:00Z

I had a short conversation with Chad Myers today over twitter (a very challenging medium to have a conversation of any substance over, and frustrating). Basically, it was about my effort with Siege.ServiceLocation. I thought I would clear up some misconceptions.

Siege.ServiceLocation isn't an abstraction, it's a decoupling.

Siege.ServiceLocation isn't just about contextual registration/resolution (though that was the initial impetus). It's not about resolution at all. It's about expressing registration. It's about adding functionality to ALL containers. There are a few things that I am trying to accomplish with this library. First, I want to decouple registration from resolution. That's not to say I want to abstract how each container's registration is performed; I want them decoupled completely. Second, I want my library to be functionally compatible with existing frameworks (see Siege Design Philosophy for more details). This means whatever Siege.ServiceLocation can do, all the frameworks it integrates with can do. Third, I want it to be easy. Outside of Ninject (which I think is a wonderfully built IoC), I think the others fail the third criteria. I've worked with them all. I know the differences. They each have distinct problems. And I don't think it has to be that way.

Inversion of Control containers should be about resolving types

Not about registering types. Registration is a way of instructing an IoC how to resolve a type. It's not what the IoC is built for, it's a way of expressing what the IoC needs to do. Each IoC has a different way of accomplishing the same thing. I've been told that choosing an IoC is about evaluating the strengths and weaknesses of each framework and picking the one that suits your needs.

What? If an IoC is there to resolve types and their dependencies, to provide a mechanism to help you decouple your code, then how can there be strengths and weaknesses in each framework? Is it in terms of how efficiently they perform the task? Is it in terms of they internally manage resolution?

Or is it in terms of what their registration syntax allows you to do? Is it in terms of how you express your goal? Is it in terms of the instructions the container understands when it tries to resolve a type?

These are all rhetorical questions. The point is to look at the problem differently than has been traditionally done. To my mind, there is a clear seperation of concerns between the responsibility of registering types and the responsibility of resolving types. I think an IoC should specialize in resolving types and their dependencies, not specialize in expressing how to resolve types and their dependencies.

Siege.ServiceLocation is not an IoC

It's a coordination mechanism for an IoC container. Think "one level above" the container. Rather than instructing an IoC container how to resolve your type, you instruct Siege.ServiceLocation. It then in turn knows how to interact with the underlying framework to get what you want. It tracks the conditions and criteria. It makes all the requests necessary through the underlying framework to get your objects constructed. Think of it as a proxy with an adapter. The goal is to track runtime conditions to facilitate the selection of an appropriate interface. To enable this functionality WITHOUT having to force you to use a specific framework. Where the IoC container specializes in resolution, Siege.ServiceLocation specializes in registration and communicating requests to the IoC container.

The reason that each IoC framework has strengths and weaknesses is because each IoC has it's own way of trying to go about describing how they want things resolved. That means that some of them can interpret certain resolution instructions. Others interpret their own resolution instructions. That's not the point of an IoC, and it's no wonder they all do it differently and each has their own strengths and weaknesses.

If we move the registration expression above the container that performs resolution, we can decouple these two concepts. Then, as long as the component that understands registration can express instructions to the component that performs resolution, all containers can suddenly benefit from these collective strengths. We remove the need for containers to worry about these concerns. We remove the need for developers to do an analysis of what "features" a container supports. We remove the need for people to make trade-offs on what strengths they gain, what weaknesses they are burdened with and what features they lose out on when choosing an IoC framework.

The Least Common Denominator

In my brief conversation with Chad, he pointed out that most abstraction attempts only manage to accomplish the Least Common Denominator of all frameworks and wind up gutting the potential of each of the frameworks they integrate with. I understand his point, but I think this is fundamentally different. The desire is NOT to limit you to what all frameworks have in common, but to allow people to use functionality that may NOT exist in all frameworks. A primary example of this is contextual resolution. Several IoCs can do this to some extent or another, based on very narrow criteria. Some of them can't do it at all. None of them can respond to evolving runtime conditions when selecting an implementation of a requested type.

When combining these containers with Siege, suddenly all of them gain this ability. This is because Siege understands both how to accomplish what you are requesting (it's specialty is in extensible registration) and how to communicate with a container to achieve it's goal (for example, when condition a is met, request type a. when condition b is met, request type b). On top of that, it instructs the container on how to call back to Siege for each dependency that a container has to resolve for additional instructions on how to perform resolution.

This means that by using Siege you can gain functionality that your selected container doesn't natively support. And as Siege's use cases grow, ALL containers functionality will grow. A rising tide lifts all boats. If the strengths of each container were built as registration expressions into Siege, all containers would gain this strength. You would would sacrifice nothing, make no trade-offs and not be required to learn multiple distinct ways to express how you want a type resolved.

Limiting your choices

One of the design philosophies behind this project is NOT to limit your choices. It's to expand them. If Siege doesn't support something that a specific container does, use that container with Siege. Do their specialized registration to configure the container and then give it to Siege to do whatever additional registration expressions you need to. With this approach, we avoid any LCD philosophy, we avoid limiting the your choices as a developer. Alternatively, you can easily extend the framework to accomplish what you want so you don't have to change containers or feel constrained to a specific one. On top of that, we deliver functionality that you would not have otherwise. And hopefully, as the framework grows and evolves, you won't have to learn 5 different ways of registering and resolving types. You'll only have to learn one, and no matter which underlying framework you use, all of them will support your system fully. But, that's down the road from where we are today, which is why I made it an important design decision to be sure we didn't rob any underlying IoC of it's functionality.

Evolution

I'll be the first to admit, this wasn't the direction that I was going when I first started working on this. I wanted to do an 80/20. But my point of view has evolved over the last month and my efforts have gone towards supporting the idea that functionality can and will be introduced to all containers through Siege. Some of the things I've had to say in this post contradict what I've said in previous posts (perhaps I should update them?) But that comes with an evolving point of view. It's organic. Things will grow and change. And I want to thank Chad for challenging me and making me think more in depth about how to articulate where I'm going and what I'm doing so I could put up a post like this.

Let each framework specialize and do what it does best. I don't expect the existing framework teams to embrace this idea. There will always be new features introduced to them. There will always be features in Siege that none of the others will have. That's the nature of the beast.

But my goal is to give you more options and to not take any away. I hope that clears up any confusion around what the intent is here.

Happy coding!

Introducing Siege.ServiceLocation.Extensions: FactoryMethod Support, Dependency Resolution based on type injected into added

2009-12-27T17:43:00Z

Introduction

For anyone wanting to follow The Siege Project, I routinely post updates on twitter (MarcusTheBold). Feel free to follow.

I did some refactoring and clean up. I'll address the specifics in a moment. First, I'll list the files for download for anyone interested:

Siege.ServiceLocation library:

Siege.ServiceLocation.zip
Siege.ServiceLocation.Extensions.zip

ASP.NET MVC Integration:

Siege.ServiceLocation.HttpIntegration.zip

IoC Framework Adapters:

Siege.ServiceLocation.AutofacAdapter.zip
Siege.ServiceLocation.NinjectAdapter.zip
Siege.ServiceLocation.StructureMapAdapter.zip
Siege.ServiceLocation.UnityAdapter.zip
Siege.ServiceLocation.WindsorAdapter.zip

Quick Start:

SiegeMVCQuickStart.zip

A few people have asked me about contributing and extending the Siege.ServiceLocation library. My preference is to keep the Siege.ServiceLocation namespace itself as the main engine for enabling a wide variety of syntaxes and not grow the default syntax beyond what comes pre-packaged (the given-when-then syntax). However, I do want the project to grow and expand to meet the needs of anyone that uses it. Therefore, I've added a new project to the Siege.ServiceLocation umbrella: Siege.ServiceLocation.Extensions

Users can download this as an optional library that works in conjunction with Siege.ServiceLocation. Contributors can contribute to this library to create new syntax and new use cases to enable users to solve problems. The only restrictions I will put on this is that it should only reference Siege.ServiceLocation and not any particular IoC or external framework. If you want to integrate with a specific IoC, or another specific framework, I do encourage you to do so -- only in a seperate project. I want to make sure that people consuming this framework don't have to add dependencies to frameworks and systems they do not intend to use.

As these particular cases come up we will address them as necessary.

So what changed?

Not a whole lot. There were some assumptions in the system around conditions and how they were evaluated that I changed to defer through an implementation via interface. What that means is that anyone extending the framework can now determine on their own how a conditions should be determined as valid for a particular use case rather than explicitly comparing against context. Additionally, I extended the framework to track the types it has been resolving. Finally, I simplified some interfaces, particularly around supporting new IoC containers. I expect that I will make a few more modifications before releasing a 1.0 version -- the execution context is a primary candidate, as right now it is fairly immature in it's implementation. The other change I anticipate is to enable the IoC to work with other cross-cutting steps during resolution. Specifically, I've been working on incorporating AOP support into Siege.ServiceLocation and it's almost complete, but I'm still pondering how to incorporate it. It may require a slight refactory, it may not. We'll see.

Once I have made these two changes I expect I'll do a feature freeze for Siege.ServiceLocation and release it as a 1.0 version.

New Features in Siege.ServiceLocation.Extensions

Included already in this project are two new types of usages: Factory Methods and the ability to resolve dependencies based on the resolution hierarchy. That is to say, you can conditionally specify types to be used when the container has already decided to use other types. As always, you can additionally refer to the unit tests for detailed examples.

Factory Methods:

You can now specify a factory method to be used when constructing an object, both by default or when a condition is met. This works nearly identically to your standard Given-When-Then functionality, except instead of "Then" you use "ConstructWith", making it a Given-ConstructWith or Given-When-ConstructWith syntax.

Type Resolution based on parent types

I'm not really sure what to call this. The syntax is like this - Given<BaseType>.WhenInjectingInto<ParentType>.Then<ImplementingType>. Basically it works like this: if you have 'BaseType1' which has a constructor dependency 'IDependency' and is implemented by 'TypeA' and 'TypeB', you can say "When you decide to resolve as 'TypeA', use the 'DependencyA' implementation of 'IDependency', otherwise use the default (if one is specified)."

By combining this with normal contextual resolution, you can set up rules for your types to be resolved based on arbitrary context and for their dependencies to be resolved either based on arbitrary context as well, or resolved based on which type is currently being resolved, or a combination thereof. It is important to note that when you specify multiple satisfiable criteria for resolution -- for example arbitrary context that is satisfied AND resolution based on a type being resolved that is ALSO true, the system will choose the first applicable use case (the first one registered). Additionally, factory method support is compatible with the aforementioned case of resolving dependencies based on the parent's type. You can tell it to use a factory when the 'WhenInjectionInto<T>' scenario is satisfied.

In Closing

The goal with this system was to be able to quickly and easily extend it to support new syntaxes and usages. When I added these new syntaxes, each of them took me roughly 30 minutes from beginning to all tests passing at the end. While I am the author of this system, I expect that the barrier for other users would not be too much higher given a very basic understanding of the interfaces involved. For example, the amount of code to support Factory Methods was maybe all told about 100 lines of code between syntax and implementation while the amount of code to support dependency resolution based on the type its injected into was less than 150 lines.

Until next time, Happy Coding!

Added support for Unity, Autofac to Siege.ServiceLocation

2009-12-23T17:23:00Z

…plus, some other house-cleaning items.

Last night I put together adapters for Autofac and Unity. The process turned out to be rather straightforward; I think all told for both it took me about an hour from adding the projects to all tests passing. I may have a final tweak for this project around how adapters work – there is one method that I think doesn’t need to be placed where it is, so I’ll probably move it. After that, I don’t anticipate many (if any) major changes to how it works … I’ll just put out a Siege.ServiceLocation.Extensions project to house more things (an auto-register, factory method support, things like that). It’ll be a good chance to prove out how extensible this really is.

Other than that I did some tweaks to namespaces to bring everything into one common scheme for namespacing. Nothing new beyond those items; I updated all the downloadable items with the latest versions. Here are the links:

Siege.ServiceLocation library:

Siege.ServiceLocation.zip

ASP.NET MVC Integration:

Siege.ServiceLocation.HttpIntegration.zip

IoC Framework Adapters:

Quick Start:

SiegeMVCQuickStart.zip

For convenience the main library is bundled with the HttpIntegration zip as well as each of the Adapter zip files.

Have a Happy Holidays!

The Siege Project: Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

2009-12-18T06:24:00Z

The Siege Project

Introduction
Siege.ServiceLocation Part 1 - Introduction and General Use
Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
Siege.ServiceLocation Part 3 – Extending the container with custom use cases
Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

The Quick Start

I’ve put together a quickstart project. You can look through the files in this project to see how everything is put together. You can get the quick start project here:

http://cloud.github.com/downloads/MarcusTheBold/Siege/SiegeMVCQuickStart.zip

Things to look at in this project:

Global.asax.cs – uses SiegeHttpApplication and shows how to hook up your ServiceLocatorAdapter (the quickstart uses Ninject) and shows where to configure the SiegeContainer.
ServiceLocatorExtensions.cs – shows how to do registrations with the SiegeContainer, both default and contextual. Also, shows how to do context on a variety of conditions, and shows how to register pre-configured instances with the UserFinder class.
AccountController – contrived, but shows an example of to work with IContextStore
The other controllers/services – basic classes that build up how the app works together

This is a purely contrived app that doesn’t really do anything. There are 4 users – Webmaster, AdminUser, TrialUser and PaidUser. For all accounts, the password is pass123. As you login as different users you should see things start happening contextually based on attributes associated with the particular user you are associated with. The different views have text explaining how they work and what to expect.

Hopefully this will give a concrete example of how things work together. As always, if you have questions, feel free to leave a comment and I will respond.

Happy coding!

The Siege Project: Siege.ServiceLocation, Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC

2009-12-18T05:10:00Z

The Siege Project

Introduction
Siege.ServiceLocation Part 1 - Introduction and General Use
Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
Siege.ServiceLocation Part 3 – Extending the container with custom use cases
Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

Get the library used to integrate with ASP.NET MVC by downloading the binaries here: http://cloud.github.com/downloads/MarcusTheBold/Siege/Siege.ServiceLocation.HttpIntegration.zip
Alternatively, you can get the source code here: http://github.com/MarcusTheBold/Siege

Combining Siege.ServiceLocation and ASP.NET MVC

By combining Siege.ServiceLocation with ASP.NET MVC, everything starts to come together. You get more than just the ability to abstract away your dependency on an individual IoC framework (and thereby allowing you to change implementations at the drop of a hat), you get the ability to react to changing conditions in your application and the individual user sessions. When resolving controllers, you have the ability to use views linked to either the contextually resolved controller, or linked to the base type that was requested. Integrating these two frameworks, it turns out, is incredibly simple to do.

SiegeHttpApplication

SiegeHttpApplication is the main component that enables you to integrate with ASP.NET MVC. Inherit your Global application in the Global.asax.cs file from this class in order to turn your regular ASP.NET MVC application into a Siege enabled application. This abstract class forces you to implement only a handful of methods and offers you the ability to override several others (not actual implementation).

public abstract class SiegeHttpApplication : HttpApplication

{

    public IContextualServiceLocator ServiceLocator;

    protected abstract IServiceLocatorAdapter GetServiceLocatorAdapter();

    public virtual void RegisterRoutes(RouteCollection routes) { }

    protected virtual IContextStore GetContextStore()

    {

    }

    protected virtual void OnApplicationStarted()

    {

    }

    protected virtual void OnApplicationStopped()

    {

    }

    protected virtual void OnApplicationError(Exception exception)

    {

    }

}

The only method you must implement is GetServiceLocatorAdapter(). This instructs the SiegeHttpApplication what underlying IoC framework you wish to use. Other than this method, you have the ability to override the default IContextStore used by the SiegeContainer (by default the HttpSessionStore is used). OnApplicationStarted, OnApplicationStopped and OnApplicationError give you extension points to provide additional logic by which you can add custom logic for your own application.

HttpSessionStore

By default, SiegeHttpApplication uses an implementation of IContextStore with the SiegeContainer called HttpSessionStore. This class stores items on the session of the user navigating your website, allowing you to control resolution on a user-by-user basis over the life of the user session. Developers can change this to any other implementation of IContextStore – GlobalContextStore to make your entire application change implementations based on context (for responding to global conditions) or to a custom implementation, if you need finer control over how context is stored and used in the resolution process.

And that’s it!

That’s all it takes to use Siege.ServiceLocation with ASP.NET MVC. I have put together a quick start application that shows in detail how all these parts work together.

Happy Coding!

The Siege Project: Siege.ServiceLocation, Part 3 – Extending the container with custom use cases

2009-12-11T04:32:00Z

The Siege Project

Introduction
Siege.ServiceLocation Part 1 - Introduction and General Use
Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
Siege.ServiceLocation Part 3 – Extending the container with custom use cases
Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

Adding new functionality to the container without having to change Siege.ServiceLocation

When I started this project, I had a few main goals in mind. I wanted to be able to register things with a straightforward and simple syntax. I wanted to be able to use any IoC framework to do the heavy lifting of type resolution for me. I wanted to be able to resolve multiple different types straight out of the container when state changed. And finally, I wanted to be able to extend it without having to constantly update the framework and put out a new release.

This post shows how I do it.

I’m going to throw a lot at you guys in short order. I’ll do my best to keep it simple and make it understandable. While simplicity has been my goal overall for this whole library, this is going to be the most involved aspect of the system. It’s not bad, I promise. The interfaces are small and the amount of code you have to implement is minimal. But there’s a few types that come into play. I’ll take the time to explain each one as we go and try to draw a simplified picture of how they work together. If anything is confusing or not clear, please reply in the comments and I’ll do my best to explain. If it’s a big topic, I’ll put up another post to go over that piece.

Let’s hit the code.

How use cases work

As I’ve mentioned in previous posts, use cases are specific implementations of the IUseCase interface. Let’s take a look at the interface.

public interface IUseCase

{

    Type GetBoundType();

    Type GetUseCaseBindingType();

    object Resolve(IInstanceResolver locator, IList<object> context);

    object Resolve(IInstanceResolver locator);

    bool IsValid(IList<object> context);

}

As you can see, there are a handful of methods that are required by this interface. Let’s go through them real quick.

GetBoundType() – this function is used by the SiegeContainer to determine the type that this particular instance of your use case is using. For example, when you do a registration like Give<IFoo>.Then<Foo>(), you get back an instance of DefaultUseCase<Foo>. When you call GetBoundType(), you will get the Foo type.
Resolve() – This method allows you to control exactly how items are resolved.
IsValid() – This method returns true if a use case is applicable according to context – false if it is not.
GetUseCaseBinding() – This returns a type (assumed to be an implementation of IUseCaseBinding) which is used to register use cases.

IInstanceResolver is one of the interfaces that IServiceLocator and IServiceLocatorAdapter inherit from. As the name implies, it resolves instances.

public interface IInstanceResolver

{

    object GetInstance(Type type, string key);

    object GetInstance(Type type);

}

In most cases you can inherit from the abstract type GenericUseCase<T>, which only forces you to implement the method GetUseCaseBinding() and manages all the other methods for you (you can of course override any you feel are necessary). All use case bindings are implementations of IUseCaseBinding, which looks like this:

public interface IUseCaseBinding

{

    void Bind(IUseCase useCase);   

}

Packaged with Siege.ServiceLocation are three use case binding types: IDefaultUseCaseBinding, IConditionalUseCaseBinding and IKeyBasedUseCaseBinding (used for registering and resolving by a particular string key). These binding types are in turn implemented by each of the adapters so that the use cases can be supported by the underlying IoC provider.

It is important to note that if you create a new type of IUseCaseBinding you will need to write concrete implementations for whatever adapter you intend to use. Custom implementations of IUseCase that use one of the bundled use case bindings do not need to do this. Only create new IUseCaseBinding types if you have specialized instructions for how you want to register and/or resolve with a specific IoC provider.

Custom types of bindings integrate easily with the container to provide seamless support for your new use case and binding. To do this, simple use the provided method on the SiegeContainer before you do your registrations:

IServiceLocator AddBinding(Type baseBinding, Type targetBinding);

Let’s take a look at a specific example.

Putting it all together

For this example, I am using Sean Chamber’s implementation of the decorator pattern as a reference point. This example will show you how to extend the container to conditionally decorate types based on runtime conditions. Bear in mind that this example is highly contrived and exists solely for the purpose of demonstration. I will be using the Ninject framework as a support for this post. All source code (including examples for all three containers) is included in the unit tests project in the source code, which is found here.

First, let’s look at the syntax to register types with decorators.

locator

    .AddBinding(typeof(IDecoratorUseCaseBinding<>), typeof(DecoratorUseCaseBinding<>))

    .Register(Given<ICoffee>.Then<Coffee>())

    .Register(Given<ICoffee>

                  .When<Ingredients>(ingredients => ingredients == Ingredients.WhippedCream)

                  .DecorateWith<WhippedCreamDecorator>())

    .Register(Given<ICoffee>

                  .When<Ingredients>(ingredients => ingredients == Ingredients.Espresso)

                  .DecorateWith<EspressoShotDecorator>());

Right off the bat you should see that I’m adding a custom binding, letting the framework know that when use cases specify IDecoratorUseCaseBinding<T> as their binding type to use DecoratorUseCaseBinding<T> as the implementation. This is one of the key parts of extending the container to support your custom registration.

public class DecoratorUseCaseBinding<TService> : IDecoratorUseCaseBinding<TService>

{

    private IKernel kernel;

    private IServiceLocatorAdapter locator;

    public DecoratorUseCaseBinding(IKernel kernel, IServiceLocatorAdapter locator)

    {

        this.kernel = kernel;

        this.locator = locator;

    }

    public void Bind(IUseCase useCase)

    {

        Bind((IDecoratorUseCase<TService>)useCase);

    }

    public object Resolve(Type typeToResolve, Type argumentType, object rootObject)

    {

        string parameterName = typeToResolve.GetConstructor(new[] {argumentType}).GetParameters().Where(parameter => parameter.ParameterType == argumentType).First().Name;

        return kernel.Get(typeToResolve, new ConstructorArgument(parameterName, rootObject));

    }

    private void Bind(IDecoratorUseCase<TService> useCase)

    {

        kernel.Bind(useCase.GetBoundType()).ToSelf();

    }

}

As you can see, DecoratorUseCaseBinding includes instructions to the container on how to register your use case with Ninject. You’ll also notice that I included a function called Resolve() on this class. This isn’t required by the interface, but I decided to keep these instructions here for the sake of simplicity in this example. Because this scenario requires objects to be specially constructed, I ask Ninject to resolve a type and give it a type argument and value to use during construction when it resolves the requested type.

The next thing you should notice about our registration is the presence of the DecorateWith<TDecorator> function. This is not included with the Siege.ServiceLocation project. I have made it up for this example. It looks like this:

public static class RegistrationExtensions

{

    public static IContextualServiceLocator serviceLocator;

    public static void Initialize(IContextualServiceLocator locator)

    {

        serviceLocator = locator;

    }

    public static IDecoratorUseCase<TDecorator> DecorateWith<TDecorator>(this IConditionalActivationRule rule)

    {

        var decoratorUseCase = new DecoratorUseCase<TDecorator>(serviceLocator);

        decoratorUseCase.BindTo(rule.GetBoundType());

        decoratorUseCase.SetActivationRule(rule);

        return decoratorUseCase;

    }

}

I decided to extend the existing registration rather than create a new class that builds instances of DecoratorUseCase. While there is nothing forcing any consumer to do this, I decided to do it so that I could leverage the existing functionality that creates rules to associate with the use case, and to show how you can bolt things on to the existing infrastructure.

Finally, let’s take a look at DecoratorUseCase. This class inherits from GenericUseCase<T> and implements the IDecoratorUseCase<T> interface. It also overrides some functionality in GenericUseCase, which I will explain.

public class DecoratorUseCase<TService> : GenericUseCase<TService>, IDecoratorUseCase<TService>

{

    private IContextualServiceLocator serviceLocator;

    public DecoratorUseCase(IContextualServiceLocator serviceLocator)

    {

        this.serviceLocator = serviceLocator;

    }

    public override Type GetUseCaseBindingType()

    {

        return typeof (IDecoratorUseCaseBinding<>);

    }

    protected override IActivationStrategy GetActivationStrategy()

    {

        return new DecoratorActivationStrategy(serviceLocator, GetBoundType());

    }

    protected class DecoratorActivationStrategy : IActivationStrategy

    {

        private readonly IContextualServiceLocator serviceLocator;

        private readonly Type decoratedType;

        public DecoratorActivationStrategy(IContextualServiceLocator serviceLocator, Type decoratedType)

        {

            this.serviceLocator = serviceLocator;

            this.decoratedType = decoratedType;

        }

        public object Resolve(IInstanceResolver locator, IList<object> context)

        {

            var useCaseBinding = (IDecoratorUseCaseBinding)locator.GetInstance(typeof(IDecoratorUseCaseBinding<TService>));

            var decorators = new List<Type>();

            var rootObject = locator.GetInstance(decoratedType);

            foreach (IDecoratorUseCase useCase in serviceLocator.GetRegisteredUseCasesForType(decoratedType))

            {

                if(useCase.IsValid(context)) decorators.Add(useCase.GetDecoratorType());

            }

            return GetInstance(useCaseBinding, rootObject, decoratedType, decorators);

        }

        private object GetInstance(IDecoratorUseCaseBinding binding, object rootObject, Type encapsulatedType, IList<Type> decorators)

        {

            if (decorators.Count == 0) return rootObject;

            Type decorator = decorators[0];

            IList<Type> prunedDecoratorList = new List<Type>(decorators);

            prunedDecoratorList.RemoveAt(0);

            object resolvedObject = binding.Resolve(decorator, encapsulatedType, rootObject);

            return GetInstance(binding, resolvedObject, encapsulatedType, prunedDecoratorList);

        }

    }

    public Type GetDecoratorType()

    {

        return typeof (TService);

    }

}

As noted earlier, by using GenericUseCase we are only required to implement the GetUseCaseBindingType() function, which returns the IDecoratorUseCase<> type as its value. This is used by SiegeContainer during registration to find the type specified in the AddBinding statement and use it to direct the underlying IoC how to register your custom implementation of IUseCase.

The GetActivationStrategy() function is overriden in this class to return a new type of IActivationStrategy. By default, GenericUseCase<T> uses a GenericActivationStrategy which simply calls GetInstance() on the IServiceLocatorAdapter. By overriding this and providing a new implementation, we are able to give the SiegeContainer high-level instructions on how to construct our object for this use case. The strategy checks all applicable use cases for the supplied context and gathers the appropriate decorator types, then recursively calls itself to build the object.

This function calls back into the binding to do the ninject-specific type resolution, which specially constructs the object for me. When it’s all said and done, I have a fully decorated object in line with the context that has been added to my IContextStore. If I specify whipped cream, I get an instance of Coffee decorated with a WhippedCreamDecorator. If I specify espresso, I get an instance of Coffee decorated with an EspressoDecorator. If I specify both, I get an instance of Coffee decorated with both.

By default SiegeContainer resolves types based on the first satisfied rule it encounters in the context, or it uses a default case. This example significantly changes how the container works by providing a mechanism for it to use ALL applicable context instead of only the first applicable context.

So that’s how it works

Extending the library is probably the most complex usages of the this project, but I hope that it is not prohibitively so. It’s also a feature that I expect will not be used as much as everything else that the container does. I’m not sure how useful the community will find this; while I have been able to recognize areas this might apply at my company, the scope of where it would be useful is fairly narrow. Still, I think it is a nice feature and a good way to show how to extend a system without having to modify its internals.

In the comments of the last post, a responder mentioned wanting to be able to use factory methods to construct objects depending on certain conditions being met. I believe that this feature enables that a developer to extend this project with that very functionality without having to go and update the project itself.

I would like very much to hear feedback on what you guys think of this. Is it too hard? Is it too confusing? Is it useful?

Until next time, Happy Coding!

The Siege Project: Siege.ServiceLocation, Part 2 - Contextual Registration and Resolution

2009-12-09T07:25:00Z

The Siege Project

Introduction
Siege.ServiceLocation Part 1 - Introduction and General Use
Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
Siege.ServiceLocation Part 3 – Extending the container with custom use cases
Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

Some house cleaning items before we get started on this post.

You can download the source code to the currently published components here: http://github.com/MarcusTheBold/Siege
You can download the binaries to the currently published components here: http://github.com/MarcusTheBold/Siege/downloads
I’m working on picking out an OSS license. I hope to have one up soon.
Some of the feedback I’ve received is to give examples of how to use this. I will put up a quick-start example in the near future and write a ‘getting started’ blog post as well.

What is Contextual Registration?

Contextual Registration, simply put, is telling the SiegeContainer that there are certain criteria that have to be met in order for a certain type to resolved. These criteria are completely arbitrary and up to the user. Perhaps you only want to resolve a particular type if the user is a super user? Maybe you integrate with multiple 3rd party vendors for a particular service and want to resolve one based on data associated with the logged in user. Perhaps you want your system to serve up different types for different states of the app, to mock 3rd party integration points or to respond to a resource being unavailable. All of these scenarios are expressable with contextual registration.

Let’s look at the example I hinted at in my last post.

locator.Register(Given<IOrderFulfillmentService>
                            .When<VendorStatus>(status => status == VendorStatus.Offline)
                            .Then<DeferredOrderFulfillmentService>());

So what does this mean? Basically, there are a handful of implementations of IUseCase packaged with Siege.ServiceLocation. The two main ones are default use cases and conditional uses cases. When you do something like, Given<Interface>.Then<ConcreteType>(), you create a default use case for the locator to use when none of the conditional use cases are satisfied.

When you use the above registration, the locator registers the type with the underlying adapter and tracks the conditions around the resolution. The literal translation of this registration is “When I ask for an instance of IOrderFulfillmentService, check to see if the vendor is offline. If it is, give me an instance of DeferredOrderFulfillmentService. If not, return me the default (if one is defined).” Using this, you can set up behaviors in your system that are tracked by the locator and resolved in your system as context begins to apply.

Where I work, we use contextual registration as a way to augment our default registrations in one of our systems, which come in the form of a pre-wired container. We change the look and feel of the website based on attributes associated with the user that is logged in. We accomplish this in large part by using contextual registration. This has been useful for us in helping to avoid having to write additional conditional logic to determine how to deliver the user experience based on data points associated with the person that is logged in.

Tracking Context for the SiegeContainer

Contextual Registration is all good and well but at the end of the day your application needs to be able to determine what types to resolve during its execution. To do this, The SiegeContainer class uses an interface called IContextStore. This interface defines how the SiegeContainer interacts with whatever underlying mechanism you decide to use to track context in your application. By default, when you instantiate a SiegeContainer, it uses an implementation called GlobalContextStore.

public SiegeContainer(IServiceLocatorAdapter serviceLocator) : this(serviceLocator, new GlobalContextStore())
{
}



public SiegeContainer(IServiceLocatorAdapter serviceLocator, IContextStore contextStore)
{
}

This context store is a very simple implementation that tracks context for the container irrespective of user session. By providing different implementations of IContextStore, you can change the way that SiegeContainer manages context for your application. This is designed to create extensibility for Siege.ServiceLocation; if there is behavior that you need that is not covered by an existing implementation, creating your own should be very easy. The definition of IContextStore looks like this:

public interface IContextStore

    void Add(object contextItem);

    List<object> Items { get; }

At our company, we use a different implementation – HttpSessionStore – to manage context on a per-user session basis. As users log in, the relevant information about them is added to the context store for use in later resolutions. I will include this context store as part of the http integration project accompanying Part 4, when it is published.

How do I add context to a context store?

This really depends on how you set up your implementation of IContextStore, or which implementation of IContextStore you are using (if you haven’t provided your own). There are a few ways of going about this. HttpSessionStore pulls items from the Session; Adding an item to the Session effectively adds it to the context. The SiegeContainer itself has a convenience method for this:

public void AddContext(object contextItem)
{
}

Alternatively, you could add things directly through your context store instance itself. Simply register the implementation of IContextStore you desire with the container and then inject it directly into a class that requires context to be updated.

locator.Register(Given<IContextStore>.Then<HttpSessionStore>());

locator.Register(Given<IContextStore>.Then(locator.ContextStore));

Using this approach, you could monitor the status of your vendor integration in the following manner:

public class VendorMonitor

    private IContextStore contextStore;

    public VendorMonitor(IContextStore contextStore)

        this.contextStore = contextStore;

    public void Monitor()

        if(IsVendorDown()) contextStore.Add(VendorStatus.Offline);

When the context store is updated, SiegeContainer will start serving different interfaces based on the rules specified for the various use cases registered and the context that exists in the container.

Contextual Resolution

So how do we go about resolving types that have been contextually registered? This turns out to be very easy. No different methods are needed to be called to resolve types contextually; Simply specify a contextual condition through registration using the Given-When-Then syntax and call GetInstance<T>() on the SiegeContainer. If the condition is satisfied, the container will return the type specified by your rule. If not, it will return the default (if specified). If multiple conditions apply, it will select the first applicable one. This is currently NOT the case for functions like GetAllInstances<T>. I am considering adding a function called GetAllContextualInstances<T> to cover this scenario.

The part (to me) that is cool is this - If you had, say, a controller class that was injected with IOrderFulfillmentService, and you resolved that controller, when the IOrderFulfillmentService is identified as a dependency, it is resolved contextually to the appropriate type. This means that contextual resolution applies not only at the root level of an object graph, but at every level a dependency is resolved and fulfilled by the container. If your object structure is 10 levels deep, and each level has constructor injected depenendencies, any of those dependencies that are contextually registered will be compared against the tracked context and resolved either to a default use case or a conditional use case. Siege works with the provided adapters to ensure that every dependency, as it is resolved, is fulfilled contextually if applicable; not only the type you are requesting, but also the types it relies on as dependencies, and the types that THOSE types rely on as dependencies.

Looking Ahead

In my next post, I will be covering how Siege.ServiceLocation has native support for extending itself to support custom use case implementations. This post will get a little deeper into the guts of how the project works and how it interacts with adapters. I hope these posts have been helpful thus far in communicating the intent of the library, how it is used, what you as a developer can do with it and how it adheres to my philosophy of simplicity, consumability and extensibility.

Until next time, Happy Coding!

The Siege Project: Siege.ServiceLocation Part 1 - Introduction and General Use

2009-12-07T04:08:00Z

The Siege Project

Introduction
Siege.ServiceLocation Part 1 - Introduction and General Use
Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
Siege.ServiceLocation Part 3 – Extending the container with custom use cases
Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

Siege.ServiceLocation

In my last post, I introduced the Siege project. While that post dealt with the goals, values and philosophies of the project, this post serves as a hands-on look at the first component to be released under the Siege umbrella. This component serves to a lesser extent as a general abstraction for service locators and dependency injection containers, providing a simple syntax for component registration. To a greater extent, this library introduces a broader type of contextual registration and allows consumers to extend the registration syntax and resolution mechanisms to account for their own custom use cases.

What is it not?

I think it's important to start off with this, because I want to set expectations clearly. This is not another IoC framework. When building this my goal was not to build yet-another-IoC from the ground up. There are plenty of projects out there that do this very well already: Castle Windsor, StructureMap, and Ninject, just to name a few. These are all good frameworks that perform their function well, and the community honestly is not in need of another one of these. My intent with this project is to be able to leverage these existing frameworks and gain the benefit of their functionality -- to stand on the shoulders of giants.

So what is it?

The Siege.ServiceLocation component is an abstraction mechanism coupled with a way to extend the existing frameworks with additional functionality. First, this component abstracts a developer away from the need to learn another subset of frameworks, with their own styles and approaches to registration and resolution of types. Secondly, Siege.ServiceLocation introduces contextual resolution to selectively resolve types based on run-time state of an application or user session. Finally, it allows developers to extend its behavior with their own custom registration and resolution behaviors.

We use this at our company to write loosely coupled frameworks that can be integrated with our various projects. Where I work, we use more than one IoC, so rather than having to rewrite a lot of registration and resolution code, we simply use a different adapter when the container is constructed.

Let's look at some code.

SiegeContainer

At the heart of Siege.ServiceLocation is the SiegeContainer class. This serves as a wrapper class for the various adapters for the different underlying IoC providers. Setting it up to use one of the various providers is easy. This is the constructor for the SiegeContainer:

        public SiegeContainer(IServiceLocatorAdapter serviceLocator)
        {
        }

The IServiceLocatorAdapter interface provides the mechanism by which we integrate with existing IoC frameworks. For example, to use Ninject as a provider for SiegeContainer, simply instantiate like this:

var locator = new SiegeContainer(new NinjectAdapter());

If you need to use a preconfigured kernel, this is also easy to do:

var kernel = new StandardKernel();
var locator = new SiegeContainer(new NinjectAdapter(kernel));

From here there are two methods that you can use to get started:

IServiceLocator Register<TService>(IUseCase<TService> useCase);
TService GetInstance<TService>();

Included in this assembly is a syntax to help build instances of IUseCase for the consumer. This syntax aligns with my goal of simplicity and covering the 80% of use cases that I mentioned in my previous post. I personally do not like verbose registration syntaxes, xml-based registration, or overly-fluent registrations. While I understand the goals and reasons for them, and I can see their use, I do not personally feel like the value added overcomes the inherent cost of learning and understanding the API. So, for my syntax, I followed the simple BDD formula. Given, When and Then.

Given<T>

Siege.ServiceLocation includes a helper class that is used for the purpose of building instances of IUseCase for the registration of types. Out of the box, this syntax supports both basic registration and contextual registration. While I will devote another post to the contextual resolution of items, I will cover briefly the method by which you contextually register items and what the purpose of contextual resolution is.

Basic (Default) Registration

Basic registration links types to implentations. This can happen between interfaces and classes, classes and subclasses, and a class and itself. Currently Siege has no mechanism to auto-register types, and a type must be either registered through Siege or registered through the underlying provider in order to be resolved. It looks like this:

Given<Interface>.Then<Type>();

and registration itself looks like this:

locator.Register(Given<Interface>.Then<Type>());

Under the covers, the container coordinates with the adapter to fulfill registration of the type. It also tracks the type internally for its own orchestration of the resolution of deep object graphs.

Contextual Registration

Contextual registration links types to implementations which are later resolved only if the specified criteria are met. The criteria for these conditional resolutions is completely arbitrary and defined by the consumer. As a developer, you can specify certain types to be returned under as simple or complex criteria as you want. Simply add context as you go to the locator and it will use that context to determine which rules have been met during resolution. SiegeContainer analyzes resolution of every dependency in an object graph no matter how deep and resolves types depending on whether or a condition has been successfully met or a default case needs to be triggered.

The syntax for the helper, Given<T>, looks like this:

        locator.Register(Given<Interface>
                      .When<ArbitraryContextItem>(contextItem == someValue);
                     .Then<Type>());

To give a purely contrived, but less abstract example, imagine you have an ordering system that integrates with a third party to fulfill requests online in real time. Sometimes this vendor is down, and you want to save the orders for later processing when this occurs.

        locator
                .Register(Given<IOrderFulfillmentService>.Then<RealtimeOrderFulfillmentService>();
                .Register(Given<IOrderFulfillmentService>
                                      .When<VendorStatus>(status == VendorStatus.Offline);
                                      .Then<DeferredOrderFulfillmentService>());

In this case, the application would contextually know to process orders in real-time or to defer them to a later time based on the status of a 3rd party integration component. This is all handled by the container, so you don't have to build additional logic into your system for determining how to handle different states of the system; This scenario assumes that there is some component performing a health check and if it fails, it notifies the locator that the state of the application is changed so it can respond accordingly. There are many different use cases for such contextually-based resolution; because the conditions are completely arbitrary, it is up to the imagination of the developer on how to use (or abuse) this feature. I will go over, in greater depth, contextual registration and resolution in the following blog post.

Extending the container

Siege.ServiceLocation is built with extensibility in mind. To that end, it has the capacity to incorporate and use custom implementations of IUseCase. While this will be covered in a seperate post, it allows a consumer to extend the container to understand how to register custom scenarios and how to resolve them. This is meant to allow myself and other members of the community to easily provide extensions to this framework without having to constantly update the source code to deliver new functionality to users.

Looking ahead

In upcoming posts, I will delve deeper into how contextual registration/resolution works, how to extend the container to incorporate custom use cases and how to integrate the framework into ASP.NET MVC. My goal is to explain how these aspects of the system work in a clear and concise manner that adheres to the main pillars of the Siege design philosophy: Keep it easy to understand and consume. Please check this framework out and leave any feedback you have in the comments section.

Happy coding!

Introducing Siege

2009-12-07T02:20:00Z

The Siege Project

Introduction
Siege.ServiceLocation Part 1 - Introduction and General Use
Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
Siege.ServiceLocation Part 3 – Extending the container with custom use cases
Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

A few months ago I wrote a post about what I consider to be good software design practices. I have thought a lot about the topic of what makes a design "good" for many months as I've worked on challenging systems both in my professional life and personal life. High coupling, massive frameworks, portability and testability problems and a plethora of other issues have helped to shape and change how I view software development. During that time, I began to work on several software projects to help me reduce coupling issues, increase reuse and testability.

Collectively, I call these this initiative Siege. This name is a wink-and-nudge towards some challenging frameworks I've used and the feeling that I've had at times of being under siege from the codebases I've had to work on.

What is Siege?

Siege represents my philosophy on software design as much as it represents a set of frameworks that I've been working on. At every design decision point, I've tried to build against my list of design values. I've reviewed the work constantly, making revisions and updates to hold the designs in line with those values as much as to ensure the code itself is functional. I will be writing blogs specifically about each component in the framework (there are a few, and will be released over time). This blog, as an introduction, serves to explain my design values and principles, why I hold them, and why they driven me to work on this project.

What are the design principles and values that Siege adheres to?

I have a small list of values that I use as guideposts for Siege. They are:

It must be easily understood
It must be easily consumed
It must be easily extended
It must be easy to maintain
It must be easy to test

That's it. Those are very broad goals, and very subjective. I've learned a lot by looking at and using other frameworks, such as Windsor, StructureMap, Ninject, NHibernate, Active Record, Rhino Commons as well as more than a few others and have come to certain conclusions about things I like about these frameworks, and things I do not. Therefore, I have developed Siege along the following convictions.

I don't like massive frameworks that over time have become monoliths. I don't like frameworks that try to solve all areas of a problem domain in one tool. I prefer frameworks that are specialized to a specific problem and address that problem. Therefore, Siege will be a component framework that will involve multiple components that work in tandem to create specific and highly-targetted solutions.
I don't like frameworks that only work with itself, or that in the process of making it easy to work with its other individual components it makes it harder to integrate other frameworks. I don't like to have a laundry list of things I must use in order for a solution to work. Therefore, Siege will be designed to integrate with other frameworks through light-weight and well-defined interfaces. Siege does not intend to reinvent the wheel, and while there may be occassional overlap of functionality, Siege will integrate as easily as possible with other frameworks to provide functionality to a consumer.
I don't like high levels of complexity in configuration and consumption of frameworks. Therefore, Siege will provide simple and straight-forward syntax to accomplish 80% of use cases while not preventing the fulfillment of the other 20%. In other words, Siege should be able to fulfill most of your normal needs, but in cases where you need a specialized component to integrate, Siege will not hinder your ability to integrate with those solutions.
I don't like rubbing up against the limitations of a framework without a way to extend it to cover my needs. Therefore, Siege will be built with extensibility in mind. You should not have to modify the framework to introduce new functionality, but rather, extend what is already there. This is a long-term goal and will require diligence to accomplish.
I do not agree with the idea of things magically working with the developer not knowing why. I don't agree with the idea of programming against a number of conventions so large that it becomes almost an exercise in learning a whole new programming language to use a tool. I do not feel that these philosophies enable a consumer to understand what is happening in their system. Therefore, Siege will not by default provide a lot of "automagical" functionality. Everything should and will be easy to trace and understand. While Siege will not behave "automagically", there will be functionality available to provide for easy of consumption while still adhering to a philosophy of "be explicit".
I do not like coupling directly to frameworks or building applications directly on them. Siege is designed to be as light-weight and non-intrusive as possible and provides abstraction mechanisms between itself and other frameworks as a result.

The bottom line is that Siege's design philosophy is to be extensible by the consumers, to provide a simple set of interfaces that developers can understand and use, and to conform to a problem and solution ... not force the problem or solution to fit to Siege.

"Talk is cheap... Show me the code."

You can access the source code to the first component I am releasing here or get the binaries here. My next posts will go over what it is (and isn't), how to use it and how to extend it. As more components are released, I will put up blog posts for those as well. There are several in the pipeline, but many of them still have a few revisions to go through to ensure that I have been as diligent as possible to not only adhere to my philosophy but also to ensure that I have as high level of code coverage as I can. I practice Test-Driven Development, but it is fair to say that many times I miss cases and have to go back and cover them. Additionally, I find in review that some functionality needs to be reworked, removed, or in some cases, new functionality needs to be added.

Happy coding!

Hallmarks of Good System Design

2009-02-26T05:14:00Z

I've had a few conversations over the last week or two with some co-workers and friends about what constitutes 'good system design'. I thought I'd post up my ideas with some short descriptions and get feedback from others. Here's my list:

1. The system is easily understood by developers of all skill levels.

I really think this is imperative. If people look at how your system is put together, look at how it functions and understand it without a lot of explanation about how it works technically, you've got a good design (explaining business domain is different). If people look at your system and are immediately lost on how it all ties together, then chances are you've either over-complicated it, written something only you can maintain, or written something that people are going to have to be trained on in order to make meaningful contributions.

There are usually more mid level and junior level people on most teams than senior levels and architects. If you have a system that can only really be maintained by senior level developers (and higher), then there's a problem. Unfortunately, many people look at these sorts of systems and the developers that write them and assume they are very intelligent/talented/gifted/what have you. It's not much different than people who converse with someone that uses a lot of "big words" (or in this industry, buzz words) that they can't understand -- they think they must be intelligent.

Being hard to understand isn't a sign of intelligence or good design. An intelligent person is someone that can explain concepts and ideas to people that don't know anything about a subject matter so that they can easily understand it. In the same way, an intelligently designed system is one that can be easily understood by developers that didn't design and build it.

2. Refactoring is not an exercise in total redesign

A well designed system is one that accomplishes exactly what the business needs today but is put together in a way that can easily be modified to support the business needs of tomorrow. Part of this is making your system loosely coupled, part of it is understanding concepts like abstraction, encapsulation and dependency inversion work. If you need to switch from your own home-grown subsystem to a 3rd party service, you should be able to create new classes and implement the interfaces defined in your system.

You should not have to tear apart how the entire system works.

Forethought must be reasonable; it is too easy to conceive an overwhelming set of situations that you may have to contend with. YAGNI is a key principle here. Use wisdom; design for today with the ability to easily refactor support for tomorrow, but don't go overboard.

3. Functionality is easily consumed

A well-designed system is one that is written with the consumer in mind; Functionality and intent should be easily understood by the person consuming it without having to dig through the implementation to make sure that it actually does what is expected. I shouldn't need some secret tribal knowledge to know what your component does; it should tell me what it does and it should do what it says. "No-ops" do not adhere to this philosophy. If your class has a function on it, that function should do what it claims to do. As a consumer, I shouldn't have to know whether or not a function I need to call will actually perform the operation that it advertises.

Functionality should be designed with ease-of-use in mind. I should be able to instantiate your object and give it whatever dependencies it requires in order to function and then execute whatever methods I need to execute in order to accomplish the objective at hand. I should not need any secret tribal knowledge on the side effects of what I pass in to these functions. If your class requires a dependency and I pass it null, don't treat it as a secret directive to start instantiating and using some predefined implementation. That is not intuitive and will not produce the results that I would expect.

4. Functionality is easily maintained

A well-designed system is one that can be maintained by anyone. Intent should be clear and easy to understand and the internals of your component should be self-descriptive along the lines of functionality provided. Methods should do one thing and one thing only. If you've written something that no one else feels comfortable trying to enhance, you've got a bad design. If your design does not make sense to other people, you have a bad design. One of the most important things about design is that it must be maintainable -- and for it to be maintainable, other people have to feel comfortable with it and be able to understand it.

Complex problems are usually a bunch of smaller, simple problems. Build solutions that are built from smaller, simple solutions.

5. Tools and frameworks should be included because the benefits outweigh the costs

There are a lot of tools and frameworks that do a lot of different things. Each of them come with a set of benefits and a set of costs. Take a great care when you choose them -- each one comes with a learning curve and will require time for developers unfamiliar with the tool to become productive with it. The more tools you throw into something, the more time it will take. Pick the tools that make the most sense for the problem you are trying to solve.

Including a tool or a framework simply because it seems 'cool' is not a valid reason. Doing it because you want to learn something new is not either. And if you need a tool or framework, be intelligent about how you introduce it as a dependency into your system. In most cases, you do not need a reference to it in every assembly. One would suffice, if you encapsulate it and interact with it through your own interfaces.

Those are a handful of things that I consider necessary for good system design. There are a lot of others, and in any design, there will always be a balancing act between many of these ideas and reality. I'd like to hear what other people think contributes to good system design.

Going down the IoC rabbit hole

2008-10-28T04:45:00Z

I've started a new position and one of the first projects I'm going to be working on relies on Windsor to do it's dependency management. Having only had a small amount of exposure before, I'm looking forward to the opportunity to learn more about the technology and the principles behind it in a practical application. For anyone with experience out there, what are the benefits and the pitfalls associated with using this?

I have a list of concerns of my own but I'm trying to keep an open mind because of my limited exposure. I'd certainly love to hear what other people think about using it and what their experiences have been like. I'll follow up with my own experiences after a few weeks.

Those pesky indexers!

2008-10-02T19:29:00Z

Those pesky string indexers.

I've worked on projects in the past where Microsoft has given developers more than enough rope to hang themselves, the rest of the team and any chance at easily maintaining the application. One common piece of rope is when they give developers a generic dictionary object to cram information into. ViewState, SessionState and recently in ASP.NET MVC, ViewData.

Giving developers these bucket-like objects is simply inviting people to make stuff up as they go. They get used as catch-alls, with people making up their own key-names ad hoc and rarely checking to see if someone else has used it. I've worked on several applications before where multiple developers decide to store the same value in something like SessionState with key names that are slightly different (userID vs userId, for example). This makes things hard to maintain as bugs creep up in a system and developers struggle to track them down. In the end, it is the fault of lazy or inobservant developers for doing it, but I lay some of the blame at a framework that makes it all too easy to do.

If things were strongly typed, it'd be easier. You'd be able to track code issues by examining uses of your interface. New "keys" would be introduced as properties to your interface, informing consumers as to what properties are already in use in the system, promoting better self-documentation. The tendancy of developers to use these objects as a catch-all for whatever piece of information they find convenient to cram inside would drop dramatically; It's harder to justify extending an interface for something that will be used once in an application than it is just to tuck it into one of these objects.

What I'm suggesting here isn't revolutionary at all but I'm constantly surprised at the number of shops that let this sort of behaviour go on.

Recently, I've been working a lot with the ASP.NET MVC framework. I love it, it's a very cool tool. But again you have a chance here to hang yourself if you're not careful by interaction with the form values and the viewdatadictionary. This has come up a handful of times with the team I'm working with, where typos have caused bugs to creep up, or people aren't aware of what information is being put into the viewdatadictionary simply because it's not very self-documenting.

Here's an example of how I'm handling this. It could be better, but it works for now.

public ViewResult AddUser()
{
IAddUserView view = new AddUserView(this.ViewData, this.FormData);
var model = new UserModel(this.UserRepository);

       User user = model.CreateUser(view.UserName);

       user.IsAuthorized = view.IsAuthorized;
       user.Email = view.EmailAddress;
       user.FirstName = view.FirstName;
       user.LastName = view.LastName;

       model.Save(user);

       return View("UserList");
}

public class AddUserView : ViewWrapper, IAddUserView
{
      public AddUserView(ViewDataDictionary viewData, NameValueCollection formData) : base("AddUser", viewData, formData) { }

      public string UserName
      {
           get { return GetData("UserName"); }
           set { this.ViewData["UserName"] = value; }
      }

      public string FirstName
      {
          get { return GetData("FirstName"); }
          set { this.ViewData["FirstName"] = value; }
      }

      public string LastName
      {
          get { return GetData("LastName"); }
          set { this.ViewData["LastName"] = value; }
      }

      public string EmailAddress
      {
          get { return GetData("EmailAddress"); }
          set { this.ViewData["EmailAddress"] = value; }
      }

      public bool IsAuthorized
      {
         get
         {
              bool? data = GetData<string, bool?>("IsAuthorized", formValue => formValue == "on", viewValue => viewValue ?? false);
              return (bool)data;
         }
         set { this.viewData["IsAuthorized"] = value; }
      }
}

public class ViewWrapper
{

      private readonly string viewName;
      protected readonly ViewDataDictionary viewData;
      private readonly FormDataIndexer formData;

      public ViewWrapper(string viewName, ViewDataDictionary viewData, NameValueCollection formData)
      {
             this.viewName = viewName;
             this.viewData = viewData;
             this.formData = new FormDataIndexer(formData);
      }

      public static implicit operator ViewResult(ViewWrapper wrapper)
      {
            ViewResult result = new ViewResult();

             result.ViewName = wrapper.ViewName;
             result.ViewData = wrapper.ViewData;

             return result;
       }

       public string ViewName
       {
            get { return viewName; }
       }

       public ViewDataDictionary ViewData
       {
           get { return viewData; }
       }

       protected string GetData(string key)
       {
          return GetData<object, string>(key, formValue => formValue == null ? "" : formValue.ToString(), viewValue => viewValue);
       }

       protected TResult GetData<TInput, TResult>(string key, Func<TInput, TResult> formEvaluation)
       {
            if (formData.ContainsKey(key)) return formEvaluation.Invoke((TInput)formData[key]);

            return (TResult)viewData[key];
      }

      protected TResult GetData<TInput, TResult>(string key, Func<TInput, TResult> formEvaluation, Func<TResult, TResult> viewEvaluation)
      {
           if (formData.ContainsKey(key)) return formEvaluation.Invoke((TInput)formData[key]);

           return viewEvaluation.Invoke((TResult)viewData[key]);
      }
}

internal interface IIndexer
{
object this[string index] { get; }
bool ContainsKey(string key);
}

internal class FormDataIndexer : IIndexer
{
     private readonly NameValueCollection formData;

     public FormDataIndexer(NameValueCollection formData)
     {
          this.formData = formData;
     }

     public object this[string index]
     {
          get { return this.formData[index]; }
     }

     public bool ContainsKey(string key)
     {
          foreach(string collectionKey in this.formData.AllKeys)
          {
               if (collectionKey == key) return true;
          }

          return false;
     }
}

This example may be a little over the top, but I really do wish development shops would see more value in coding against interfaces instead of writing hard-to-maintain code against bucket objects like the above, or things like SessionState or ViewState. It doesn't take much effort to make a SessionWrapper and expose things as properties, and it would make life a lot easier for people trying to track down bugs.

Of course, just because you build it doesn't mean they can't ignore it and use the buckets anyway... but if that happens, then it's a different problem all together.

Procedural LOLCoding

2007-10-28T22:39:00Z

Recently I had the great pleasure to be introduced to LOLCode. It's an idiomatic syntax based on a series of images found at LOLCat and ICanHasCheezeBurger. In any event, currently LOLCode syntax is at specification 1.2. There are several compilers including a LOLCode.NET compiler. I gave it a try, but as of the time of this posting, it didn't seem to be able to handle if statements too well.Currently in specification 1.2, everything is still procedural, though there are proposals for OOP LOLCode in the proposed 1.3 specification. I thought for fun I'd post up some LOLCode snippets from a tic tac toe program I wrote in LOLCode to see if I could get it to work.

HOW DUZ I CheckForWinningMatch YR index1 AN YR index2 AN YR index3 AN YR array

BOTH SAEM array!!index1 AN array!!index2, O RLY?
YA RLY
BOTH SAEM array!!index1 AN array!!index3, O RLY?
YA RLY
BOTH SAEM array!!index1 AN "X", O RLY?
YA RLY
FOUND YR WIN
MEBBE BOTH SAEM array!!index1 AN "O"
FOUND YR WIN
OIC
OIC
OIC

FOUND YR FAIL

IF U SAY SO

The above code snippet checks a one dimensional array (I don't think it supports multidimensional arrays yet, though I could be wrong) for combinations of the letters X and O for any sort of winning combination. Some of LOLCode syntax includes:

Functions declarations in LOLCode start with "HOW DUZ I" and end with "IF YOU SAY SO".
IF statements are equivilent to "O RLY?" and and equivilency is expressed as "BOTH SAEM".
"YA RLY" indicates a positive match, and "NO WAI" indicates a negative match on the condition.
"MEBBE" corresponds to "else if"
If statements are closed with "OIC" (oh, I see)
Return statements are expressed as either "FOUND YR", followed by a value, or as "GTFO" which returns a void
The !! operator acts as an indexer, though my understanding is that in OOP LOLCode it may be used to access properties and methods as well
The TROOF data type (boolean), is expressed as either WIN (true) and FAIL (false)\
Other data types include BUKKIT (array), NOOB (null), NUMBAR (float), NUMBR (int), YARN (string)
The SMOOSH keyword handles string concatenation
Programs start with HAI and end with KTHXBYE

Here is my "main" method's code.

HAI

I HAS A array ITZ A BUKKIT
I HAS A char ITZ "X"

       DrawTicTacToe array

       IM IN YR LOOP

BOTH SAEM GetWinningCombination array AN WIN, O RLY?
YA RLY
VISIBLE SMOOSH char " is winnar!!"
                       GTFO
OIC

               GetUserInput char array

DrawTicTacToe array

BOTH SAEM char AN "X", O RLY?
                       YA RLY
char R "O"
NO WAI
char R "X"
               OIC

IM OUTTA YR LOOP

KTHXBYE

I grabbed a java compiler from the LOLCode website that appears to have support for the proposed 1.3 specs.

OOP LOLCode, here I come!

Aspect-oriented approaches to software development

2007-10-25T14:39:00Z

A while back, I wrote a little post alluding to ways to reuse certain processes that are duplicated in code throughout any given system (event logging, in my example). In this post, I'd like to show you how I implemented a possible solution using aspect oriented programming.

What is Aspect Oriented Programming?

Basically, the idea that there are types of processes that occur in multiple places in a system, commonly referred to as "cross-cutting concerns". Aspects are implementations of these concerns, written so that they can be reused in a system. In the logging example, the need to log exceptions is a concern, and the aspect is a piece of code that fulfills this need. The idea behind aspect oriented programming is to identify these cross-cutting concerns, create aspects to manage them, and introduce their behaviors into the points of a system that their behavior needs to govern. In my example, I will accomplish this by creating some custom attributes and aspects as well as decorating classes and methods. As these objects are instantiated and their methods are invoked, I will be intercepting messages and injecting the behavior defined by my aspect.

A Consumer's View

Here is my simplistic implementation:

public class HelloWorld
{
     public void SendGreeting()
     {
            Messenger messenger = new Messenger();
            messenger.SendMessage("Hello World!");
     }
}

Running this code produces the following "logged" output:

Attempting connection...
Logging Exception: A problem occurred!

All right, so how does this work? Here's my messenger class.

[Loggable]
public class Messenger : ContextBoundObject
{
     [LogException]
     public void SendMessage(string message)
     {
          Console.WriteLine("Attempting Connection...");
          throw new Exception("A problem occurred!");
     }
}

First thing you might notice is that it inherits from a class called ContextBoundObject. By inheriting from this class, we will recieve the context needed from the runtime and intercept messages in order to extend the invocation of SendMessage to include the behavior defined by our aspect. Also, there are two different types of attributes being used here... [Loggable] and [LogException].

[Loggable]

The [Loggable] attribute is a context attribute used to associate our Aspect into the message chain. Below is the source code.

[AttributeUsage(AttributeTargets.Class)]
public class LoggableAttribute : ContextAttribute, IContributeObjectSink
{
      public LoggableAttribute() : base("Loggable") { }

      public override void GetPropertiesForNewContext(IConstructionCallMessage msg)
      {
            msg.ContextProperties.Add(this);
      }

      public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink)
      {
            return new LogExceptionAspect(nextSink);
      }
}

The implementation here is fairly straight-forward. The attribute can only be used with classes and when it is instantiated, it will add itself to the message's context and add our aspect to the message chain for execution. Also, when instantiating LogExceptionAspect, we give it a reference to the next message sink in the chain, allowing us to insert our aspect as a link in the chain.

[LogException]

The [LogException] attribute is a simple attribute that houses our logging code, and can only be used on methods.

[AttributeUsage(AttributeTargets.Method)]
public class LogExceptionAttribute : Attribute
{
     public void Process(string message)
     {
          new EventLogger().LogMessage(message);
     }
}

LogExceptionAspect

The LogExceptionAspect class, which is part of the [Loggable] context attribute's implementation, is a message sink. When the chain of message sinks is being processed, the runtime will get a reference to this class and invoke IMessage.SyncProcessMessage. This function will house code related to our logging process.

public class LogExceptionAspect : IMessageSink
{
       private readonly IMessageSink nextMessageSink;

       public IMessageSink NextSink
       {
            get { return this.nextMessageSink; }
       }

       public LogExceptionAspect(IMessageSink nextMessageSink)
       {
            this.nextMessageSink = nextMessageSink;
       }

       public IMessage SyncProcessMessage(IMessage msg)
       {
            MethodBase method = RemotingServices.GetMethodBaseFromMethodMessage((IMethodMessage)msg);

            FormatExceptionAttribute formatException = (FormatExceptionAttribute)Attribute.GetCustomAttribute(method, typeof(FormatExceptionAttribute));
            LogExceptionAttribute logException = (LogExceptionAttribute)Attribute.GetCustomAttribute(method, typeof(LogExceptionAttribute));             ReturnMessage response = (ReturnMessage)this.nextMessageSink.SyncProcessMessage(msg);

if (response.Exception == null) return response;

string message = response.Exception.Message;

if (formatException != null) message = formatException.FormatException(response.Exception);
if (logException != null) logException.Process(message);

return response;
}

      public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)
      {
            return this.nextMessageSink.AsyncProcessMessage(msg, replySink);
      }
}

As you can see, in this aspect, we get a reference to the method and check for possible attributes ([LogException] and [FormatException]) and run the rest of the chain. At this point in execution, exceptions do not get thrown, so there is no need for any try/catch constructs. Simply check the resulting message for exceptions, and if any are detected, format and log the exception if the function has been decorated with attributes directing the aspect to do so.

As you can see in the above example, I have introduced another attribute called [FormatException]. This is simply to illustrate that multiple attributes can be associated with the aspect and you can decorate your functions as desired with one, both or neither directives for the aspect to adhere to. Here is the definition for [FormatException]:

public class FormatExceptionAttribute : Attribute
{
     public string FormatException(Exception exception)
     {
         return new EventFormatter().FormatException(exception);
     }
}

and the definitions for the logger and event formatter:

public class EventLogger
{
     public void LogMessage(string message)
     {
         Console.WriteLine("Logging exception: " + message);
     }
}

public class EventFormatter
{
     public string FormatException(Exception exception)
     {
          return "Formatted Exception: " + exception.Message;
     }
}

If I add [FormatException] in my Messenger class, the output changes to:

Attempting connection...
Logging Exception: Formatted Exception: A problem occurred!

In Closing

I see some nice benefits and some unfortunate drawbacks to the way .NET handles this. The need to inherit from ContextBoundObject is something I really don't like and causes me to be hesitant in trying to implement something like this. Additionally, it would require a certain level of competancy for anyone that wants to maintain this code. However, this does prevent a lot of try/catch/log exception/throw; code repetition and could be altered to allow one to easily inject whatever sort of logging/formatting mechanisms they want to use, or even actions they want to take based on type of exception. Furthermore, it allows developers to write try/catch statements only in cases where they want to handle exceptions and resolve them, and it allows developers that use it to focus on writing code to accomplish the task at hand instead of writing code (yet again) to log exceptions that arise in the system.

What does that function do, really?

2007-08-03T02:06:00Z

Recently, I had the chance to read a blog by one of my former coworkers on the topic of code duplication and functional programming. I found the ideas there interesting; in many applications that I deal with there are certain repeated processes. For example, functions try a certain statement, catch a possible exception and log the information to the event log. Pretty standard process. So in reading this blog I came to a simple conclusion. There are at least two types of code that are duplicated: Functional Code and Procedural Code (not to be confused with functions and procedures). One of them is often refactored and reused... one of them is not. Take the following code example:

public class DataManager
{
      public void SaveData()
      {
          try
            {
                  //Do something
            }
             catch(Exception ex)
            {
                   EventLogger logger = new EventLogger();
                   logger.LogException(ex);
             }
       }
}

Functional Code

Functional code is code that accomplishes a certain task. In this example, I have intercepted an exception in the system and I am going to log it to the event log. So I write a class with a method that takes messages in and inserts them into the event log. This code fulfills a function in this system -- it ensures that messages it receives are persisted in the designated medium (the event log, in this case). Duplicate code here is easily refactored into an object that provides an interface to the event log, with methods for managing events and it acts as an application boundary for the system. The segments of code within the try, and within the catch are functional code segments.

Procedural Code

Procedural code is code that governs how your functional code is implemented. This code fulfills a process of the system -- it ensures that when an exception occurs, the appropriate piece of functional code is executed. In the above example, this is the code that manages when your event logging class is used -- it is the code that tries a statement, catches some exception, and invokes the logger. It's something seen repeated in a lot of functions in a lot of applications.

Reading the above blog, I thought it was a neat way to refactor this into a reusable process. But, I felt that while the procedural code had been abstracted a bit, calls to it would still be scattered through my systems, and I was hoping to remove it from my implementation all together.

So why is this important? By refactoring functional code into reusable objects, you can change the internal implementation of that object without impacting the rest of your system. But what about the steps your system takes in order to fulfill that function? What if you want to amend that process to do additional steps before logging that exception?

Often times this sort of code is placed upon the object that is performing the function itself. Let's amend my original example of event logging to include message formatting. In our modified example, the object's behavior is defined as accepting a message, formatting that message, and then logging it. While the formatting of the message is clearly procedural -- it is a step the system takes to prepare for logging -- many people will dump it with functional code. Take for example, the following sample:

public class EventLogger
{
      public void LogException(Exception exception)
      {
            string message =  new ExceptionFormatter().FormatExceptionMessage(exception);
            this.WriteToEventLog(message);
      }
}

Alternatively, you could pass the appropriate formatter to the function:

public class EventLogger
{
      public void LogException(Exception exception, IExceptionFormatter formatter)
      {
            string message =  formatter.FormatExceptionMessage(exception);
            this.WriteToEventLog(message);
      }
}

This intially seems to make sense to do. The first example reduces code duplication because the presumption is that all error messages will need to be formatted before being logged. However, from the standpoint of the consumer of this class, one would expect this method to take an exception and send it to the event log. One would not be aware that formatting would be occuring on the message. This design produces unexpected behavior from the standpoint of the consumer and becomes an implicit and non self-documenting aspect of the object. Although it clearly logs messages to the event log, it also has unclear additional behavior. Furthermore, if a developer implements the second sample, the consumer also has to be aware of exception formatting in order to log messages, resulting in a more difficultly consumed interface. One could simply rename the method in either sample to "FormatAndLogMessage", but honestly this addresses the symptom of the problem, and not the problem itself.

The Seperation of Concerns

What I'm getting around to is that there is a clear seperation of concerns here. Event Logging should not be concerned with Message Formatting. These are seperate concerns and the functional code to fulfill each concern should be ignorant of the other. This would imply that the procedural code in first sample should somehow be amended in the try/catch to perform message formatting before logging. If logging were performed like this throughout the system, this approach would actually increase code duplication instead of solve it! Furthermore, one would expect a function like SaveData() would simply do as it says -- save the data. However in our above sample, the seperation of concerns is apparently violated by the fact that SaveData() not only saves information, it logs exceptions to the event log!

Fortunately, there is a way to resolve this issue in a relatively simple manner, reducing procedural code duplication and seperating concerns within our functional code segments while producing a readable, self-documenting interface. This can be accomplished declaratively by use of attributes.

[Loggable] and [LogException]

Assume for a moment that the above scenario could be implemented in this fashion:

[Loggable]
public class DataManager
{
      [LogException]
      public void SaveData()
      {
             //Do something
      }
}

This implementation is a much simpler, more elegant way to address the problem. In this example, there is no procedural code within SaveData(), only functional code. Exception logging has been abstracted away from our codebase and reclassified as a system concern. This is a good thing -- it allows our code to focus purely on the needs of the business instead of having to also manage the needs of the system. In this implementation we have extended the way in which the system is expected to address exceptions during execution declaratively, augmenting the way in which our code executes without affecting the way our code is implemented.

So what about exception formatting? Using this approach, we should easily be able to extend our design to address this concern as well.

[Loggable]
public class DataManager
{
      [FormatException, LogException]
      public void SaveData()
      {
             //Do something
      }
}

or, if you prefer to use more than one formatter:

[Loggable]
public class DataManager
{
      [FormatException(typeof(ExceptionFormatter)), LogException]
      public void SaveData()
      {
             //Do something
      }
}

This allows us to identify both exception message formatting and exception logging as procedural aspects of our system and abstract those concepts away from our functional code declaratively, producing less code to maintain through code reuse and more readable code by focusing our written code on what is important -- the functionality.

So how useful is this? Fairly useful, in my opinion. It would allow developers to draw clear distinctions declaratively between system needs and business needs. Operations like event logging, operation retrying and using transactions are some easy examples of where this could be implemented to reduce code duplication. The key is knowing when and what types of procedural code make good candidates for this sort of approach.

In my next post, I will show how the procedural code in our first sample is abstracted into attribute usage and implemented in .NET to produce the final examples, touching on something I came across while trying to figure out how to accomplish this -- Aspect Oriented Programming.