Archive for November, 2009

400 Posts

5 commentsWritten on November 29th, 2009 by
Categories: About The Blog

This is the 400th post on this blog. I used to have a 'tradition' where i posted the most popular recent posts whenever i hit another round number in the post count. Since i've been bombarding you guys with links to previous posts a little bit too much in the past couple of weeks, i decided to end that tradition from now on.

Instead, i'd like to ask you for some feedback on what you'd like me to focus on in the next 100 posts. Are there any specific things you'd like me to cover? Is there any topic you'd like me to cover more? Is there any topic you'd like me to cover less? Basically, i want to hear from you what i can do to make you enjoy this blog more. Are there certain things that you'd like me to change when it comes to diversity of content, writing style, layout, whatever...?

I obviously can't make any promises, but i will try to consider your suggestions as much as possible :)

Agatha 1.0 Beta 2 Is Out

7 commentsWritten on November 29th, 2009 by
Categories: agatha

I just released Agatha 1.0 Beta 2... while the changes aren't spectacular, i considered them important enough to release a new version.

Here's the changelog:

  • Logging in the servicelayer now happens through the Common.Logging instead of using log4net directly... which means you can use whatever logging library you prefer
  • (Breaking Change): If you want to pass your container instance to an Agatha container wrapper, you have to pass it to the constructor of the wrapper, and then pass that IContainer instance to your ServiceLayerConfiguration or ClientConfiguration instance before initializing
  • Added Agatha.Unity and Agatha.Unity.Silverlight
  • Added simple example of Agatha in use, with a small service layer, an IIS host for the service layer, a .NET client which performs a synchronous and an asynchronous client, and a Silverlight client which also performs an asynchronous call

The 2 most important changes are obviously that you can now integrate your own IOC container more easily and cleanly, and that you can use whatever logging library that you prefer. If you download the source of beta 2, you'll also get the example solution which shows you how easily you can start using Agatha in your projects.

You can download the bits here.

Integrating Your IOC Container With Agatha

8 commentsWritten on November 28th, 2009 by
Categories: agatha

Agatha relies on the presence of an IOC container, both client-side as well as server-side.  When it was still a closed-source library used by my company, we could get away with using our preferred IOC container (Castle Windsor) directly.  Obviously, when making an open-source library available you want your users to have the ability to not only use their preferred container, but to integrate with their container as well.  With ‘integrate’ i mean that it should be possible to register Agatha’s components in your container, so that you can easily resolve Agatha components (such as the IRequestDispatcher or the IAsyncRequestDispatcher), or to have the ability to have the container automatically inject your dependencies (which are registered in your container) in your Request Handlers (which are resolved and used by Agatha).

I originally planned to use the Common Service Locator project for this, because the project description certainly seemed to fit my need:

The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.

Unfortunately, the shared interface defined in this project only contains method for resolving components.  I really wanted to avoid having an Agatha-user be responsible for the correct registration of each component in their container, so the Common Service Locator project doesn’t really offer me any benefits.  Instead, i defined my own IContainer interface in Agatha which looks like this:

    public interface IContainer
    {
        void Register(Type componentType, Type implementationType, Lifestyle lifeStyle);
        void Register<TComponent, TImplementation>(Lifestyle lifestyle);
        void RegisterInstance(Type componentType, object instance);
        void RegisterInstance<TComponent>(TComponent instance);
 
        TComponent Resolve<TComponent>();
        object Resolve(Type componentType);
 
        void Release(object component);
    }

This interface enables me to perform automatic registration of all of the required components, and whenever Agatha needs to resolve components it will also do so through an instance which implements this interface.  We currently have two specific implementations of this interface: one for Castle Windsor, the other for Unity.  I’m going to cover how these implementations work later on in this post (as it will be useful to anyone who wants to use another IOC container together with Agatha) but first i want to show how Agatha will either obtain a reference to your container, or instantiate its own container if you don’t give it a container instance.

Agatha has two configuration classes: ServiceLayerConfiguration and ClientConfiguration.  ServiceLayerConfiguration defines the following constructors:

        public ServiceLayerConfiguration(Assembly requestHandlersAssembly, Assembly requestsAndResponsesAssembly, IContainer container)
        {
            // not relevant to this post, so i'm skipping this
        }
 
        public ServiceLayerConfiguration(Assembly requestHandlersAssembly, Assembly requestsAndResponsesAssembly, Type containerImplementation)
        {
            // not relevant to this post, so i'm skipping this
        }

And ClientConfiguration defines the following ones:

        public ClientConfiguration(Assembly requestsAndResponsesAssembly, IContainer container)
        {
            // not relevant to this post, so i'm skipping this
        }
 
         public ClientConfiguration(Assembly requestsAndResponsesAssembly, Type containerImplementation)
        {
            // not relevant to this post, so i'm skipping this
        }

As you can see, you can pass either an instance of an object that implements Agatha’s IContainer interface, or you can just pass in the type of the IContainer implementation.  If you pass in an instance, Agatha will simply reuse that instance for both the registration and the resolving of components.  If you pass a type instead of an instance, Agatha will create its own instance and use that for the registration and resolving of components.

Now, how do you integrate your own container? Quite simple, just create a type which implements the IContainer interface and pass an instance of that type to Agatha’s configuration objects.  As an example, i’ll show how i did it for Castle Windsor.  I created a new assembly called Agatha.Castle which contains the following Container class:

using System;
using Agatha.Common.InversionOfControl;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
 
namespace Agatha.Castle
{
    public class Container : IContainer
    {
        private readonly IWindsorContainer windsorContainer;
 
        public Container() : this(new WindsorContainer()) {}
 
        public Container(IWindsorContainer windsorContainer)
        {
            this.windsorContainer = windsorContainer;
        }
 
        public void Register(Type componentType, Type implementationType, Lifestyle lifeStyle)
        {
            var registration = Component.For(componentType).ImplementedBy(implementationType);
            windsorContainer.Register(AddLifeStyleToRegistration(lifeStyle, registration));
        }
 
        public void Register<TComponent, TImplementation>(Lifestyle lifestyle)
        {
            Register(typeof(TComponent), typeof(TImplementation), lifestyle);
        }
 
        public void RegisterInstance(Type componentType, object instance)
        {
            windsorContainer.Register(Component.For(componentType).Instance(instance));
        }
 
        public void RegisterInstance<TComponent>(TComponent instance)
        {
            RegisterInstance(typeof(TComponent), instance);
        }
 
        public TComponent Resolve<TComponent>()
        {
            return windsorContainer.Resolve<TComponent>();
        }
 
        public object Resolve(Type componentType)
        {
            return windsorContainer.Resolve(componentType);
        }
 
        public void Release(object component)
        {
            windsorContainer.Release(component);
        }
 
        private static ComponentRegistration<TInterface> AddLifeStyleToRegistration<TInterface>(Lifestyle lifestyle, ComponentRegistration<TInterface> registration)
        {
            if (lifestyle == Lifestyle.Singleton)
            {
                registration = registration.LifeStyle.Singleton;
            }
            else if (lifestyle == Lifestyle.Transient)
            {
                registration = registration.LifeStyle.Transient;
            }
            else
            {
                throw new ArgumentOutOfRangeException("lifestyle", "Only Transient and Singleton is supported");
            }
 
            return registration;
        }
    }
}

The Agatha.Castle.Container class defines two constructors.  One is the default constructor, which will create a new instance of the Windsor container, and the other requires you to pass an instance to a Windsor container.  The rest of the type simply implements Agatha’s IContainer interface methods and delegates to the real container instance.  If you pass an instance of the Agatha.Castle.Container class to Agatha’s ServiceLayerConfiguration class, Agatha will use this type to register and resolve all components.  Which means it either reuses your container instance, or creates its own if you don’t pass one (which i’d only recommend if you’re not using an IOC container in your code). This makes it pretty easy to integrate whatever IOC container you want to use. 

Agatha currently has ‘out-of-the-box’ support for Castle Windsor and Microsoft’s Unity.  If you want to use your own container, you now know how easily you can integrate it with Agatha.  And i’d be very happy to accept patches which add more Agatha.YourPreferredContainer assemblies :)

The Biggest WHY Comment I’ve Ever Seen

5 commentsWritten on November 26th, 2009 by
Categories: Off Topic

One of my coworkers wrote the following WHY comment yesterday:

// __          ___    ___     __    ___ 
// \ \        / / |  | \ \   / /   |__ \
//  \ \  /\  / /| |__| |\ \_/ /       ) |
//   \ \/  \/ / |  __  | \   /       / /
//    \  /\  /  | |  | |  | |       |_| 
//     \/  \/   |_|  |_|  |_|       (_) 
//
// Because the normal ChildWindow causes a memoryleak.
// The memory leak was created because the ChildWindow subscribed to the RootVisual_GotFocus multiple times...

A Reading Guide To Becoming A Better Developer

21 commentsWritten on November 25th, 2009 by
Categories: Code Quality, Opinions

I've stated previously that reading software development books is a good way of investing in your skills and your career. But which ones should you read? And in what order should they be read? I've compiled a list of books that i think can truly increase your skills substantially. I've put them in the order in which i believe they will have the most effect, and grouped them in 3 'stages'. I primarily have young developers who are just getting started as professional developers in mind with this list, but it should be just as useful to developers who've been around for a while and simply want to improve.

The first thing that you should focus on is improving your ability to write clean, unambiguous, maintainable code. The following books should greatly help you with that:

  1. Test-Driven Development (Kent Beck)
  2. Refactoring (Martin Fowler)
  3. Implementation Patterns (Kent Beck)
  4. Code Complete: 2nd Edition (Steve McConnell)
  5. Working Effectively With Legacy Code (Michael Feathers)
  6. Clean Code (Robert C. Martin)

The order of this stage might surprise some people, but i'm willing to bet that this is the most efficient order to reading those books.

After you've learned how to write great code, you should really start focusing on clean design and architecture. That's not to say that you should focus solely on design and architecture, but the more you know about it, the better off you will be:

  1. Design Patterns (Gang Of Four)
  2. Patterns Of Enterprise Application Architecture (Martin Fowler)
  3. Domain-Driven Design (Eric Evans)
  4. Enterprise Integration Patterns (Gregor Hohpe, Bobby Woolf)
  5. Release It! Design and deploy production-ready software (Michael T. Nygard)
  6. 97 Things Every Software Architect Should Know (edited by Richard Monson-Haefel)

This stage probably deserves a bit of clarification as some of the books listed in this part might be somewhat 'controversial'. If you read and learned from the books in the first stage, then you should be capable of putting everything you read in the second stage in perspective. You will have learned that you shouldn't just apply as many patterns as possible, but it's certainly a good thing to know about their existence.

Finally, you need to learn about working in a team environment and understanding team dynamics. The following books aren't about working in teams specifically, but contain a tremendous amount of wisdom and insight that will definitely help you when it comes to working in a professional team environment:

  1. Extreme Programming Explained, Second Edition (Kent Beck)
  2. The Art Of Agile Development (James Shore & Shane Warden)
  3. The Mythical Man-Month, 20th Anniversary Edition (Frederick P. Brooks)

This one probably needs a bit of clarification as well. I'm not saying that you should do Extreme Programming. But it certainly won't hurt you to learn about it, and at least try to apply the practices that you believe in when it makes sense to do so. You don't really need to apply them all (though you will get bonus points from the cool kids if you do so, or at least pretend to), but there are a few of them that everyone really should do regardless of which agile variant you subscribe to.

So there you have it... try those books out in that order, and don't forget to thank me later :P