I just came back from lunch at the Barcamp Klagenfurt and would like to post my presentation slides.

Posting the code samples is rather useless since I did some live coding on stage, but I am working on a post on the topic anyway, so you will see the code sooner or later.

Anyway, the slides are here (pptx): Barcamp-Klagenfurt-windsor.pptx

I shipped a accounting application in January and got asked to implement some new features into the software lately.
That customer I worked for on that project was absolutely amazing, we really found a common ground to communicate about the needs of the business and my implementation of it. I tried to apply domain driven design as much as possible, and it really worked out exceptionally well.
The customer now has a basic knowledge of what I’m doing and how I’m doing that, while I understand most of his business needs and how to translate those to code.

The dark side of this is that the customer now started to use the system in ways I never intended it to because he knew how to achieve his desired output.

For example, the system has no built-in support for selling set-products. Meaning that buying 1 meta product actually is selling 5 different products for a different set-price.

We once briefly talked about that feature, but neglected it to get more important stuff done, and it never came up since then.

Turns out, the customer implemented that feature himself, by creating a product representing the set, and whenever selling it, he added the set and the 5 sub products to the order. Changing the price of the 5 sub products to zero caused the bill to appear right while still removing the items from storage.

This bit me yesterday when I was asked to implement another feature did some calculations that aren’t based on the actual sell price of the products but on their base price. This screws my complete calculation because now that data is indistinguishable from another kind of data in the system that has to be treated differently.
So I end up with a new type of sale that the system has no means of identifying (without doing some rather complicated and error prone rule matching stuff I want to avoid).

Now, a rather trivial feature has turned into a major system refactor since I need to re-implement the set functionality and some creative ways how to fix the old sales to reflect that change.

Time I would have rather spent working on other things, instead of running with scissors :).

Watch out for how you communicate with your customers and make sure they tell you anything about the system and their intended uses. If you give them enough power through the UI, they will start to fill in bogus values to achieve their business needs without you knowing.

The following code is extensible and configurable:

public class Worker
{
    private IValueCalculator valueCalculator = new DefaultValueCalculator();


    public IValueCalculator ValueCalculator
    {
        get { return valueCalculator; }
        set { valueCalculator = value; }
    }

    public decimal Work(int number)
    {
        return valueCalculator.Calculate(number);
    }
}

What happens here is that I am using the strategy pattern to implement different behaviors to keep my Worker class safe from changes to the calculator code.
Basically I’m doing dependency injection here, but I don’t inject the class through the constructor but through setter injection.

Since I am not bound to the construction phase of the object, I can easily swap IValueCalculator implementations during the worker’s lifetime without having to reconstruct the whole object.

Now, why is this extensible AND configurable?

It’s extensible because it’s easy to implement the IValueCalculator interface and supply it to a worker instance, without changing any of the plumbing around it.
If I want to change the behavior for just one call i can do that very easily:

var worker = new Worker();
var oldCalculator = worker.ValueCalculator;
worker.ValueCalculator = new AlternativeCalculator();
worker.Work(1701);
worker.ValueCalculator = oldCalculator;

But the real beauty of the whole thing is that an inversion of control container like Castle Windsor can also inject setters, so in absence of a configuration file, the default implementation from the code will be used.

But once a Windsor configuration is found you can swap the strategy classes through the configuration even without recompiling like this:

<components>
    <component 
        id="Worker"
        type="Blog_Sample.Worker, Blog_Sample" />
    <component
        id="Alternative.Calculator"
        service="Blog_Sample.IValueCalculator, Blog_Sample"
        type="Blog_Sample.AlternativeCalculator, Blog_Sample" />
</components>

If you want the default behavior just delete the Alternative.Calculator component and no setter injection will happen. If a service implementing IValueCalculator is present that one will be injected to the Worker.

"Anything that can go wrong, will go wrong."

Today is one of those days where I really expect UFOs to land or drunk reindeers to drop some white bearded guy off at my doorstep. It can’t possibly get any worse does it?

First thing I look out of the window to see everything covered in snow right when I’m already late to an appointment, then I finally realize that my laptop is broken.

Now, back at home I went up to the attic where I keep all hardware boxes I acquired during the last 10 years and searched for the DELL OEM support CDs I got with my sweet little laptop.

Guess what? Nowhere to be found.

Turns out, my little brother bought himself a Dell Inspirion 1530 Laptop some time ago. When the Laptop came it turned out that it lacked the required GPU power (they just switched the 15XX series from Nvidia 8600M to ATI X1330 graphics) so he sent it back and got a refund on his money.

Now, what also happened was that my Laptop box was lying around right next to his laptop box on our attic, so when he repacked his laptop to send it back, he accidentally packaged it in my box.
So, not only did that box contain all the packaging material I keep around in case I need to send stuff back, no it also contained all driver and support disks (and the bundled Creative Headphones I got with the XPS).

So now I’m really screwed in a way because I am having trouble with a Laptop that is running Windows 7, I have no way of restoring it to Windows Vista, and I have to explain to Dell that the problem is not caused by Windows 7 because it also was there when I used Vista.

Oh, and while at it. I can’t find the bill and shipping notice for my laptop at the moment.
What a great day. I wish I had given in to that voice in the morning telling me to stay in bed because I felt sick.

I guess my laptop is officially broken. I am currently digging for my Dell Support CDs to reinstall Vista on it, but I don’t really think that will help at all(except with the Dell support people).

I do credit the crashes to my hardware simply because I’ve been a Vista user on multiple machines since day 1 and know how rock solid the OS really is.
I suspect the mainboard of my laptop to be faulty in some way.

The funny thing is (besides that my laptop fails to boot 50% of the time), I am still doing active development on that machine.
It works, I see some weird errors sometimes, but I can still work normally on the system once it’s booted.

While creating a Windsor XML configuration for a new project today I found myself looking too much at the reference to get started. I figured this may be because of the lack of a schema that would provide me Intellisense in Visual Studio. Shockingly I couldn’t find a xsd schema file for the Windsor configuration.

I then looked at some w3schools tutorials and figured out how to do a xsd schema myself and tried to remodel the Windsor configuration reference.

You can grab the xsd schema file here: windsor-configuration.xsd

I’ll post a little tutorial on how to load it inside Visual Studio later.

So, apparently Google has decided to finally get rid of Feedburner and moved their services over to new servers. 
That means new feed URLs for everyone, also for me.

The new Feed URL is: http://feeds2.feedburner.com/Tigraine

I changed the little subscribe button to the right, and Google has also put redirects on the old URL pointing to the new one. So, existing subscribers shouldn’t see any change.

Since I already moved (not the smartest thing), if you can read this in your reader, everything is fine.

Yes indeed, there have things changed.

After doing so much Winforms development lately I am finally back on the Web side once again. But this time not in swamped webforms land but breathing the fresh air of ASP.NET MVC. You may already know that because I’ve been already ranting about the platform and it’s love for HttpContext.

Anyway, this post is not about MVC, it’s about the great Rob Conery who made my day when I watched the first episode of his MVC Storefront series.

What impressed me?
This is the first and only sample I have seen come out of Microsoft that did not involve dropping a data grid right out of SQL server into the app, tweaking two properties and concluding: “And that’s how easy you can do xy with Microsoft XY.NET”

This is the first demo I see that did really feel like a real world solution and not like demo ware put together in an attempt to impress people with how little work is required to do something.
Developing software is hard, and it takes time and thought.
And Rob sharing his thoughts on testability, separation of concerns and his clever use of the repository pattern is just great fun to watch and follow.

This new way feels good.
I watched that webcast while deciding the structure of a very important project and it helped me very much in getting a better idea of how to tackle MVC. So, thank you very much Rob!

Oh, and yeah, I know I’m late to the party. Rob has put out 25 webcasts of the MVC Storefront series, it just happened that my attention was focused on NHibernate, Windsor, Winforms and RhinoMocks lately. I also have to admit that I dislike Webcasts since you can’t just scan through them to find out if you are interested or not.

Since I’m doing more and more layering I also started to split up my layers into different projects so I can’t bypass any layer by accident.

This leads to solutions with 10+ projects sometimes (tests, setup, etc..) and that looks like this sometimes:

So, that’s great and I can only recommend that. You get much better view over what dependencies your application has internally.

But that leads to one problem: Versioning the assemblies.
I don’t want to go through 10 projects changing AssemblyInfo.cs to correspond to the real version of my application. Since I only do the splitting into different projects to ease development, I always want all assemblies to have the same version. So, how to tackle this?

Simple: Create one master AssemblyInfo.cs (just copy one of the existing ones), and delete the others from the other projects. We want to re-insert the file, but this time as a link so changes to one AssemblyInfo.cs cause all projects to have a changed assembly information.

Yes, that’s right. There is a way to reference a file without copying it into the folder (well hidden behind that arrow there).

So, now the file shows up in the solution explorer twice, but changes will spread to other projects too:

When having a MSI project, it won’t update a referenced assembly during setup if there hasn’t been a change to it’s version number. So I ended up installing a new version of the GUI component while the changes in the controller assembly didn’t install because there was no increment in version number. Annoying, but not so much of a problem once you know how to handle it :).

ASP.NET MVC was designed to be a very “clean” and testable framework for creating web applications from Microsoft. And they failed really badly in one place: HttpContext!

The fact that the ASP.NET MVC Contrib project has a whole project dedicated to mocking out the whole HttpContext for testing simply illustrates one point: It’s broken, period.
There is this one gigantic god hash table that has 5 other hash tables hanging from it that knows everything about the incoming request. And although it’s possible to fake the whole thing with RhinoMocks (as the MVC Contrib guys do it), it’s still a pretty stupid idea to have all those concerns in one class called “context” (and accessible to the controller code).
So, although the HttpContextBase is already an abstraction of the real context, I wanted to extract those things into specialized service classes that I have full control over (and that could then be used for even more specialized classes that handle data retrieval, thus making “magic strings” go away when dealing with requests and sessions).

I set out to create a request service class that follows a very simple Interface:

public interface IRequestService
{
    string GetRequestField(string fieldName);
}

The actual class is just a Facade for the HttpRequestBase class that gets injected into the constructor.

Problem here: I would have to new up this IRequestService in my controller, and that’s something I didn’t want to do. Object graph construction shouldn’t be in the controller at all, and so I want to inject IRequestService instances into the controller. And that can’t be done without control over the ControllerFactory.

The IControllerFactory interface is rather simple, and it’s the perfect place to leverage the power of a IoC framework to construct the controller objects.
So I simply pass the object creation off to Windsor in the CreateController method:

public class ControllerFactory : IControllerFactory
{
    private WindsorContainer container = new WindsorContainer(
                                        new XmlInterpreter(new ConfigResource("castle")));


    public IController CreateController(RequestContext requestContext, string controllerName)
    {
        
        return (IController)container.Resolve(controllerName);
    }

    public void ReleaseController(IController controller)
    {
        var disposeable = controller as IDisposable;
        if (disposeable != null)
            disposeable.Dispose();
        container.Release(controller);
    }
}

What then took ages for me to figure out was how to instruct Windsor to use current HttpContext.Request object. Turns out, I was searching in the wrong place: That functionality is in MicroKernel and not in the Windsor container.

public IController CreateController(RequestContext requestContext, string controllerName)
{
    container.Kernel.AddComponentInstance<HttpRequestBase>(typeof (HttpRequestBase),
                                                           requestContext.HttpContext.Request);
    return (IController) container.Resolve(controllerName);
}

The AddComponentInstance method allows you to pass in a concrete instance that should be used when searching for a service. This way when Windsor constructs the RequestServiceFacade class that takes a HttpRequestBase as dependency it will simply inject the one specified instead of trying to construct the HttpRequestBase itself (that doesn’t work ;)).

This now allows me to easily swap out request implementations by just changing the Windsor configuration.