When it comes to the number of arguments to pass to a function, Uncle Bob is pretty clear. Quoting from Clean Code:

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided when possible. More than three (polyadic) requires very special justification – and then shouldn’t be used anyway.

Still, some objects might have more than 3 attributes or properties and you usually need some way to initialize them via the constructor. Some attribute might not be mandatory, therefore on some occasions you can get by with a few overloads adding more parameters as needed.

Consider the following (contrieved) example from the world of soccer. I have picked a few attributes that encapsulate the concept of a Team.

namespace Soccer
{
    public enum Color
    {
        White,
        Red,
        Green,
        Blue
    }

    public class Team
    {
        string Name { get; set; }
        string NickName { get; set; }
        Color ShirtColor { get; set; }
        string HomeTown { get; set; }
        string Ground { get; set; }

        public Team(
            string name,
            string nickName,
            Color shirtColor,
            string homeTown,
            string ground)
        {
            Name = name;
            NickName = nickName;
            ShirtColor = shirtColor;
            HomeTown = homeTown;
            Ground = ground;
        }
    }
}

Let’s try initializing one team:

Team team1 = new Team(
    "Manchester United",
    "The Red Devils",
    Color.Red,
    "Manchester",
    "Old Trafford");

In this case we are passing 5 arguments into the constructor. Consider that most of the parameters is a string, therefore it’s quite easy to get confused and invert the order of some parameter (the first two or the last two). The compiler would not be able to help in this case.

What may help here is a builder object with a fluent interface which can help specifying all the attributes of the team. Something like the following:

TeamBuilder tb = new TeamBuilder();
Team team2 =
    tb.CreateTeam("Real Madrid")
        .WithNickName("Los Merengues")
        .WithShirtColor(Color.White)
        .FromTown("Madrid")
        .PlayingAt("Santiago Bernabeu")
        .Build();

Let’s see the code for the TeamBuilder class:

public class TeamBuilder
{
    private string name;
    private string nickName;
    private Color shirtColor;
    private string homeTown;
    private string ground;

    public TeamBuilder CreateTeam(string name)
    {
        this.name = name;
        return this;
    }

    public TeamBuilder WithNickName(string nickName)
    {
        this.nickName = nickName;
        return this;
    }

    public TeamBuilder WithShirtColor(Color shirtColor)
    {
        this.shirtColor = shirtColor;
        return this;
    }

    public TeamBuilder FromTown(string homeTown)
    {
        this.homeTown = homeTown;
        return this;
    }

    public TeamBuilder PlayingAt(string ground)
    {
        this.ground = ground;
        return this;
    }

    public Team Build()
    {
        return new Team(name, nickName, shirtColor, homeTown, ground);
    }
}

The only catch in the solution above is that the caller needs to call Build() at the end of the call chain.

We can improve the solution using an implicit user-defined type conversion operator:

public class TeamBuilder
{
    private string name;
    private string nickName;
    private Color shirtColor;
    private string homeTown;
    private string ground;

    public TeamBuilder CreateTeam(string name)
    {
        this.name = name;
        return this;
    }

    public TeamBuilder WithNickName(string nickName)
    {
        this.nickName = nickName;
        return this;
    }

    public TeamBuilder WithShirtColor(Color shirtColor)
    {
        this.shirtColor = shirtColor;
        return this;
    }

    public TeamBuilder FromTown(string homeTown)
    {
        this.homeTown = homeTown;
        return this;
    }

    public TeamBuilder PlayingAt(string ground)
    {
        this.ground = ground;
        return this;
    }

    // CONVERSION OPERATOR
    public static implicit operator Team(TeamBuilder tb)
    {
        return new Team(
            tb.name,
            tb.nickName,
            tb.shirtColor,
            tb.homeTown,
            tb.ground);
    }

This allows you to create new teams in a more natural way as follows:

TeamBuilder tb = new TeamBuilder();

Team team3 = tb.CreateTeam("Chelsea")
    .WithNickName("The blues")
    .WithShirtColor(Color.Blue)
    .FromTown("London")
    .PlayingAt("Stamford Bridge");

The above solution, albeit quite simple, is a good starting point. To make it ready for real-world code, you should making it more robust with some error checking (what happens if I omit some call from the chain? If I pass an invalid argument? Etc…).

More, you might want to hide the actual implementation from the clients and extract an interface or abstract class from the concrete TeamBuilder. This is left to the reader as an excercise

Floating Points and Rounding Errors.

Working with floating points number can sometimes provide some (un)pleasant surprise, since many real numbers do not have a finite representation and this can lead to rounding errors.

If you need to refresh your knowledge (and have some time to spare), you can find a great treatment in the article What Every Computer Scientist Should Know About Floating-Point Arithmetic:

Squeezing infinitely many real numbers into a finite number of bits requires an approximate representation. Although there are infinitely many integers, in most programs the result of integer computations can be stored in 32 bits. In contrast, given any fixed number of bits, most calculations with real numbers will produce quantities that cannot be exactly represented using that many bits. Therefore the result of a floating-point calculation must often be rounded in order to fit back into its finite representation. This rounding error is the characteristic feature of floating-point computation.

A small example should make the problem clearly visible:

class Program
{
    static void Main(string[] args)
    {
        double a = 22.4;
        double b = a / 131;

        double c = 0;
        for (int i = 0; i < 131; i++)
        {
            c += b;
        }

        Console.WriteLine("Are they equal?: {0}", a == c);
        Console.WriteLine("Difference (a - c) is {0} ", a - c);
    }
}

Here we are taking a double (a), diving it by 131 and then creating a new number (c) by adding the result of that division 131 times. By pure math, a and c should be equal. If you try this small program yourself, this is the output that you would get:

Are they equal?: False
Difference (a - c) is -4,9737991503207E-14

As you can see, the result is not what you might expect, and it's affected by a rounding error that is building up every time b is added to the partial result c.

Note that this is dependent on the number that I have chosen. If you substitute 131 with 5, you will not experience this problem.

Your Own Comparer

Sometimes this behavior might annoy you, especially when you don't need such a high precision and a “rough” equality is all you need. A typical situation is unit testing an algorithm against some expected result: your assertions may fail because of a rounding error, even though the logic of your algorithm is formally correct.

In such a case, you might want to implement your own comparer. A desirable property for such a comparer is a threshold value: if the difference between two floating points is below that threshold they are considered equal.

All you need is to implement the .NET interface IEqualityComparer interface.

class DoubleComparer : IEqualityComparer
{
    private readonly double threshold;

    public DoubleComparer(double threshold)
    {
        this.threshold = threshold;
    }

    public bool Equals(double x, double y)
    {
        return Math.Abs(x - y) < this.threshold;
    }

    public int GetHashCode(double obj)
    {
       return obj.GetHashCode();
    }
}

I have created my own comparer to use in my unit tests. I only have to implement 2 methods: Equals() and GetHashCode().

I don't care much for the actual algorithm of the hashcode implementation, so I am reusing double own algorithm.

Instead, I have applied my own logic to the Equals method: to me, two doubles are equal if the absolute value of their difference is within a given threshold (which I can pass to the comparer in the constructor).

The Comparer In Use

Suppose I have an algorithm to calculate the histogram of a given collection of doubles, and a unit test to validate the calculation against a collection of expected results.

In the example below, samples are the input values which I want to create the histogram for, and expectedBreaks is a sequence containing the left and right limits of the bins of the histogram (in the example I am requiring 5 bins, so the number of breaks is 5 + 1 = 6).

var p = new HistogramProvider();
double[] samples = { 20, 12, 4, 22, 19, 24, 9, 5, -12.2, 13, 0 };
double[] expectedBreaks = { -12.2, -4.96, 2.28, 9.52, 16.76, 24 };

var histogram = p.CreateHistogram(samples, 5);

Assert.IsTrue(expectedBreaks.SequenceEqual(
                       histogram.Breaks,
                       new DoubleComparer(0.01)));

I have figured out the threshold to pass (0.01) based on the relative size of the doubles under analysis. Of course, you should use your own judgement to come up with a sensible threshold according of the range of your input data.

The following is an example of a service containing both generic method calls and generic types.

public interface IContainer<T>
{
    IEnumerable<IProperty<T>> Properties { get; }
}

public interface IPropertyService
{
    IContainer<T> GetProperties<T>(string propertyCode);
}

Now suppose that you don’t know the actual type of the data until runtime (possibly because the type is retrieved from a DB or from some other service). You need a way to interact with these generics, and Reflection can help you here.

Let’s assume that you have managed to get the Type of the data that you are handling (such as string, decimal, double, etc…) and that you have a concrete implementation of the IPropertyService (perhaps through Dependency Injection).

Once you have that, you can invoke the GetProperty method in the following way:

Type type = // ... this is the actual runtime type
IPropertyService service = // ... this is an instance of the service

Type serviceType = typeof(IPropertyService);
MethodInfo getPropertiesInfo =
    serviceType.GetMethod("GetProperties", new Type[] { typeof(string) });

if (getPropertiesInfo == null)
{
    // Uh-oh.... has the interface changed after we wrote this? Throw an exception...
}

Type[] genericArguments = { type }; // we only have one generic argument (<t>)
MethodInfo getPropertiesMethodInfo =
    getPropertiesInfo.MakeGenericMethod(genericArguments);

// Finally invoke the method to search for a price
var propertiesContainer =
    getPropertiesMethodInfo.Invoke(service, new object[] { "price" });

As you can see are quite a few steps to be performed, but at the end, through reflection, you end up with a container filled with all the objects that you have required.

Now assume that you want to access to the single properties contained in the IContainer. You need some way to invoke the C# property Properties. defined on IContainer. Similarly to the MethodInfo class, System.Reflection has a PropertyInfo class that you can use to work with Properties.

The following solution, despite compiling fine, will not work at run-time:

PropertyInfo containerInfo = typeof(IContainer<>).GetProperty("Properties"); // WRONG!!!
if (containerInfo == null)
{
    // the interface has changed. Throw an exception
}

var properties = containerInfo.GetValue(container, null) as IEnumerable;

If you try to run this, you will be greeted by the following exception: Late bound operations cannot be performed on types or methods for which ContainsGenericParameters is true.

After scratching my head for a while, I realized that I should have first created a generic type at run-time before retrieving the PropertyInfo:

Type containerType = typeof(IContainer<>).MakeGenericType(type);
PropertyInfo containerInfo = containerType.GetProperty("Properties");
if (containerInfo == null)
{
    // the interface has changed. Throw an exception
}

var properties = containerInfo.GetValue(container, null) as IEnumerable;

At this point I have a collection of IProperties which I can enumerate through. If needed, since the types in this collection are also generic, I need to repeat the process above until I reach a fundamental type (such as string, double, etc…).

Introduction

Almost 10 years ago now I used to be a Java developer in Motorola. After a long hiatus in the embedded systems and a job change, I have come back to enterprise development, this time in .Net.

I remembered that in the good ol’ days it required 2 steps to see the final rendering of the XML documentation: firing javadoc (usually from within an ANT task) and the open up the content in a browser.

I was quite surprised to see that in the .Net area seeing the final output of the docs was not as straightforward as I hoped for. Yes, there was NDoc to parse the XML, but its development stopped around 2005 and it’s doesn’t support anything beyond C# 2.0. There’s also Sandcastle, but to make it work for me it has required a few downloads and a bit of tweaking here and there. And integrating it into my NAnt task had not been that easy either. But somehow in the end I have pulled that out.

Therefore I have been pleasantly surprised when I met CR Documentor, a little plug-in for visual studio that let’s you see your XML documentation as you write it. It’s almost like having a WYSIWYG editor, without having to launch Sandcastle, wait for the complete build, and open up the browser.

Installation

• Requirements:
  • Visual Studio 2005 or greater (I am pretty confident that you need at least a Professional version as opposed to Express). I am running it on Visual Studio Team System 2008, not sure whether it works also on 2010.
  • The DXCore plugin framework from DevExpress. Possibly the best (and only?) way to get it is to get through the excellent free CodeRush Xpress for C# and VB
• Download the plugin: CR Documentor is hosted at Google Code at this link.
• Copy the dll in your DX-Core plugin-folder (C:\Users\<username>\Documents\DevExpress\IDE Tools\Community\PlugIns)
• Restart Visual Studio

Usage

1. CR Documentor adds itself in the right click menu, close to the bottom. From the submenu, choose “Show CR_Documentor window”.
2. A new window opens up in floating mode (I prefer to dock-it to the right side together with my solution explorer and luckily the plug-in remembers this choice every time I open the window after closing it and at startup).
3. Now every time your cursor is on an XML doc, you can see the preview in the Documentor window. See for example when I put the cursor on the XML doc of a class: I get a complete picture of the documentation for that class and its methods all in real time.
   
4. There are a few other features that I don’t use very often. All of them are accessible by the right-click content sensitive menu:
   • Expand/Collapse all XML comments in the editor
   • Insert XML docs templates (I prefer to use GhostDoc for that).

Configuration

Like all DXCore plugins, you can access to the configuration by pressing ALT+CTRL+SHIFT+O combination. I like to check all my options to Sandcastle because that’s the tool that I will be using to create the final XML documentation.

This is the third post of a series on the Service Locator pattern. In the first post I described how to create a basic service locator for your C# application, while in the second post I introduced lazy initialization of the services.

We now add another piece to our puzzle, transforming the Service Locator class into a singleton.

The Singleton Pattern

The singleton is arguably the most known and controversial design pattern. Some say singletons are good, some says singletons are evil. Eric Gamma himself (one of the Gang Of Four) in a recent interview stated that (emphasis added):

When discussing which patterns to drop, we found that we still love them all. (Not really—I’m in favor of dropping Singleton. Its use is almost always a design smell.)

I don’t have a strong opinion either way; I tend to use it sparingly and in the following code I will show how to apply this pattern to the service locator. There are already countless blogs discussing the pros and the cons of the singleton pattern, therefore I won’t discuss about it any further.

The Singleton Service Locator

The following was our initial implementation (other details of the classes have been removed for clarity). The constructor was internal, allowing all potential clients from within the assembly to invoke it. Clients could either pass around a reference to the created service locator, or instantiate new instances each time:

internal class ServiceLocator : IServiceLocator
{
    // a map between contracts -> concrete implementation classes
    private IDictionary<Type, Type> servicesType;

    // a map containing references to concrete implementation already instantiated
    // (the service locator uses lazy instantiation).
    private IDictionary<Type, object> instantiatedServices;

    internal ServiceLocator()
    {
        this.servicesType = new Dictionary<Type, Type>();
        this.instantiatedServices = new Dictionary<Type, object>();

        this.BuildServiceTypesMap();
    }

    // rest of the methods
 }

To implement the singleton pattern, we make the constructor private and provide clients with a static method through which we can retrieve an instance of the service.

Note how the creation of the single instance of the ServiceLocator class is itself lazy and thread safe. There are a few variations on the theme when it comes to singleton thread safe initialization (see for example this post by Jon Skeet).

internal class ServiceLocator : IServiceLocator
{
        // a map between contracts -> concrete implementation classes
        private IDictionary<Type, Type> servicesType;
        private static readonly object TheLock = new Object();

        private static IServiceLocator instance;

        // a map containing references to concrete implementation already instantiated
        // (the service locator uses lazy instantiation).
        private readonly IDictionary<Type, object> instantiatedServices;

        private ServiceLocator()
        {
            this.servicesType = new Dictionary<Type, Type>();
            this.instantiatedServices = new Dictionary<Type, object>();

            this.BuildServiceTypesMap();
        }

        public static IServiceLocator Instance
        {
            get
            {
                lock (TheLock) // thread safety
                {
                    if (instance == null)
                    {
                        instance = new ServiceLocator();
                    }
                }

                return instance;
            }
        }

        // rest of the methods
 }

Clients will now simply invoke the GetService() method through the singleton instance, without having to create a new object each time:

IServiceA service = ServiceLocator.Instance.GetService<IUniverseFileServiceAdapter>();

The Problem of Circular References

Recently I had to model a tree-like structure using a variation of the GoF composite design pattern and to pass this class to a WCF service for further processing.

The class has circular reference as described by the following drawing:

Therefore off I went to naively create my DataContract along the following lines:

[DataContract(Namespace = "http://schemas.acme.it/2009/10"]
public class Node
{
	[DataMember(Name="Children", Order=2)]
    private IList<Node> children;

    [DataMember(Name="Id", Order=0)]
    public string Id { get; set; }

    [DataMember(Name="Parent", Order=1)]
    public Node Parent { get; set; }

    public Node()
    {
        children = new List<Node>()
    }

    public void AddChild(Node node)
    {
        this.children.Add(node);
        node.Parent = this;
    }

    public IList<Node> Children
    {
        get
        {
            IList<Node> result = new List(this.children);
            foreach (Node child in this.children)
            {
                foreach (Node innerChild in child.Children)
                {
                result.Add(innerChild);
                }
            }

            return result;
        }
    }
}

Unfortunately at run time I was greeted by the following exception:
Object graph for type 'System.Collections.Generic.List`1[[Node ...]]' contains cycles and cannot be serialized if reference tracking is disabled..

The Solution

Reading around I realized that up until some time ago you had to implement your own DataContractSerializer (see for example this post by Sowmy Srinivasan).

Luckily, it turns out that with NET 3.5 SP1 everything is much simpler: you just have to use the IsReference parameter in the DataContract attribute, as follows:

[DataContract(Namespace = "http://schemas.acme.it/2009/10", IsReference=true)]
public class Node
{
    // everything same as in the example above.
}

The Catch

For some reason, if you turn on the IsReference attribute, then you cannot set the IsRequired attribute to true on any DataMember of the DataContract. The reason is somehow explained here.

In my previous post Service Locator Pattern in C#: A Simple Example I introduced a fairly basic implementation of this pattern. In this post I will address one of the limitations of that implementation, introducing a form of lazy initialization.

Defining Lazy Initialization

Lazy initialization improves the performance of object creation, deferring long running initializations until they are really needed.

Suppose for example that some of the fields of an object need to be read from the database. If a client never access those fields, accessing the database to retrieve those fields has been useless and it has just made object initialization slower (often by a considerable factor).

Martin Fowler credits Kent Beck with the introduction of the lazy initialization pattern, and in PoEAA book he describes it in the following way:

The basic idea is that every access to the field checks to see if it’s null. If so, it calculates the value of the field before returning the field. To make this work you have to ensure that the field is self-encapsulated, meaning that all access to the field, even from within the class, is done through a getting method.

Fairly simple.

The Improved Service Locator

The following is the improved version of the service locator which uses lazy initialization of the services.

internal class ServiceLocator : IServiceLocator
{
    // a map between contracts -> concrete implementation classes
    private IDictionary<Type, Type> servicesType;

    // a map containing references to concrete implementation already instantiated
    // (the service locator uses lazy instantiation).
    private IDictionary<Type, object> instantiatedServices;

    internal ServiceLocator()
    {
        this.servicesType = new Dictionary<Type, Type>();
        this.instantiatedServices = new Dictionary<Type, object>();

        this.BuildServiceTypesMap();
    }

    public T GetService<T>()
    {
        if (this.instantiatedServices.ContainsKey(typeof(T)))
        {
            return (T)this.instantiatedServices[typeof(T)];
        }
        else
        {
            // lazy initialization
            try
            {
                // use reflection to invoke the service
                ConstructorInfo constructor = servicesType[typeof(T)].GetConstructor(new Type[0]);
                Debug.Assert(constructor != null, "Cannot find a suitable constructor for " + typeof(T));

                T service = (T)constructor.Invoke(null);

                // add the service to the ones that we have already instantiated
                instantiatedServices.Add(typeof(T), service);

                return service;
            }
            catch (KeyNotFoundException)
            {
                throw new ApplicationException"The requested service is not registered");
            }
        }
    }

    private void BuildServiceTypesMap()
    {
        servicesType.Add(typeof(IServiceA),
            typeof(ServiceA));

        servicesType.Add(typeof(IServiceB),
            typeof(ServiceB));

        servicesType.Add(typeof(IServiceC),
            typeof(ServiceC));
     }
}

We are now maintaining two separate maps:

• servicesType maps an interface describing a service to a type T that implements that interface.
• instantiatedServices maps an interface to an instantiated object of class T.

Both maps are initialized in the constructor. However only the first map is filled. Every time GetService is invoked, we check whether a concrete implementation of that service has already been created. If not, we create that service implementation retrieving its constructor via reflection, and we put a reference to that implementation in the instantiatedServices map.

For this to work, the service implementation needs to expose a default (parameterless) constructor.

If services creation time is significant, lazy initialization can save you quite some time during application start up, with very little cost in terms of increased complexity.

Next article in the series: A Singleton Service Locator

In my current project I have found myself needing to parse a CSV file coming from a legacy C++ application. This is a fairly common task, and in the past I have always written the parsing engine myself, especially when there was some validation related to the business logic involved.

This time I have chosen to try the reportedly excellent FileHelpers library. Why reinvent the wheel yet another time? The library is well documented and in a matter of minutes I was able to start experimenting with some test data.

To simplify the discussion, suppose that the CSV file has the following structure:

# City, Date, Temperature
Chicago; 20090913 07:00:00; 62.23
New York; 20090913 08:00:00; 81.3

Each row of the CSV file is mapped to the following class:

[DelimitedRecord(";")]
[IgnoreEmptyLines()]
[ConditionalRecord(RecordCondition.ExcludeIfBegins, "#")]
public class CsvRecord
{
    public string City;

    [FieldConverter(ConverterKind.Date, "yyyyMMdd HH:mm:ss")]
    public DateTime Date;

    [FieldConverter(ConverterKind.Double, ".")]
    public double Temperature;
}

The attributes are pretty self-explanatory: they specify which is the separator value and which lines can be ignored.

The interesting part here is the way FileHelpers allows to specify a pattern to convert a string into a DateTime value. In this case, the pattern used here is yyyyMMdd HH:mm:ss to match the CSV file.

Once the mapping between the CSV and the .NET object is setup, I have created a class wrapping the FileHelpers engine (just in case some day I want to change the parsing engine), with the following (simplified) method:

public IEnumerable<CsvRecord> GetRecordsFromFile(Stream s)
{
   FileHelperEngine engine = new FileHelperEngine(typeof(CsvRecord));
   s.Seek(0, SeekOrigin.Begin);

   CsvRecord[] records = engine.ReadStream(new StreamReader(s)) as CsvRecord[];
   return records;
}

This was working like a charm… until I moved the code to a separate test machine. All of a sudden the parser would complain that it could not parse the dates from the file. After a lot of thought, I realized that the test machine had a different regional settings: while my machine had English formats, the test machine had Italian formats. And for some reason FileHelpers was not able to work correctly in this scenario (even though I had explicitly specified the date and time pattern in the CsvRecord class).

Luckily, FileHelpers lets you specify your own converters if the predefined ones won’t do. I therefore created my custom converter for the dates as follows:

public class CustomDateTimeConverter : ConverterBase
{
    private const string DateTimeFormat = "yyyyMMdd HH:mm:ss";

    public override object StringToField(string from)
    {
        return DateTime.ParseExact(from, DateTimeFormat, CultureInfo.InvariantCulture);
    }
}

and rewritten the CsvRecord class as follows:

[DelimitedRecord(";")]
[IgnoreEmptyLines()]
[ConditionalRecord(RecordCondition.ExcludeIfBegins, "#")]
public class CsvRecord
{
    public string City;

    [FieldConverter(typeof(CustomDateTimeConverter))]
    public DateTime Date;

    [FieldConverter(ConverterKind.Double, ".")]
    public double Temperature;
}

This time it worked also with Italian locale.

Frankly, I don’t know why the FileHelpers class had problems with the Italian locale (possibly with locales different from English ones). Probably having a look at the source code would reveal the truth.

I suspect that it is parsing the dates with a given format but without specifying an invariant culture format provider. But that is just a wild guess.

A few readers of my previous post on File Transfer with WCF have asked to share the implementation of the UploadFile and DownloadFile methods.

While I can’t share the complete implemention of the service for obvious Intellectual Property reasons, I will outline the basic steps involved in implementing the service. Please refer to my previous post for the details on the DataContracts and OperationContracts involved here.

NOTE: I have extracted these portions from the actual code. I cannot verify this to work as-is, but it should give you a head-start to complete your own service. You should also add your own error checking, and any pre or post-download and/or pre or post-upload processing as required by the business.

Download

public FileDownloadReturnMessage DownloadFile(FileDownloadMessage request)
{
    // parameters validation omitted for clarity
    string localFileName = request.MetaData.LocalFileName;

    try
    {
        string basePath = ConfigurationSettings.AppSettings["FileTransferPath"];
        string serverFileName = Path.Combine(basePath, request.MetaData.RemoteFileName);

        Stream fs = new FileStream(serverFileName, FileMode.Open);

        return new FileDownloadReturnMessage(new FileMetaData(localFileName, serverFileName), fs);
    }
    catch (IOException e)
    {
        throw new FaultException<IOException>(e);
    }
}

Upload

public void UploadFile(FileUploadMessage request)
{
    // parameters validation omitted for clarity
    try
    {
        string basePath = ConfigurationSettings.AppSettings["FileTransferPath"];
        string serverFileName = Path.Combine(basePath, request.MetaData.RemoteFileName);

        using (FileStream outfile = new FileStream(serverFileName, FileMode.Create))
        {
            const int bufferSize = 65536; // 64K

            Byte[] buffer = new Byte[bufferSize];
            int bytesRead = request.FileByteStream.Read(buffer, 0, bufferSize);

            while (bytesRead > 0)
            {
                outfile.Write(buffer, 0, bytesRead);
                bytesRead = request.FileByteStream.Read(buffer, 0, bufferSize);
            }
        }
    }
    catch (IOException e)
    {
        throw new FaultException<IOException>(e);
    }
}

A Service Locator is a common design pattern that allows decoupling clients of services (described by a public interface) from the concrete class implementing those services. Martin Fowler has a great introduction on the topic in his Inversion of Control Containers and the Dependency Injection pattern.

What follows is a very simple service locator implementation in C# based on generics.

Let’s start defining the contract of a service locator.

public interface IServiceLocator
{
    T GetService<T>();
}

Now let’s see a very simple implementation of this contract:

class ServiceLocator : IServiceLocator
{
	// map that contains pairs of interfaces and
	// references to concrete implementations
	private IDictionary<object, object> services;

	internal ServiceLocator()
	{
		services = new Dictionary<object, object>();

		// fill the map
		this.services.Add(typeof(IServiceA), new ServiceA());
		this.services.Add(typeof(IServiceB), new ServiceB());
		this.services.Add(typeof(IServiceC), new ServiceC());
	}

	public T GetService<T>()
	{
		try
		{
			return (T)services[typeof(T)];
		}
		catch (KeyNotFoundException)
		{
			throw new ApplicationException("The requested service is not registered");
		}
	}
}

As you can see,

• the constructor of the class registers all the available services in a dictionary. In our example, we have 3 different services accessible through IServiceA, IServiceB, and IServiceC. It is assumed here that ServiceA implements IServiceA and so forth.
• the generic GetService() method returns a reference the correct implementation fetching it from the dictionary

This is how a client would invoke the service:

IServiceLocator locator = new ServiceLocator();
IServiceA myServiceA = locator.GetService<IServiceA>();

The clients do not know the actual classes implementing the service. They only have to interact with the service locator to get to an implementation.

Improvements

This is as simple as it gets. There are several improvements that a real-world implementation of a service locator should consider (what follows is only a partial list):

• The service locator itself might be a singleton. There usually is no need to have two instances of a service locator.
• Lazy initialization of services might be considered. In the example above, the constructor creates new instances for all possible services; initialization might be deferred until some client actually requests a particular service.
• The mapping between interfaces and implementation might be more flexible using metadata (e.g. through application configuration files)

Next article in the series: Service Locator Pattern in C# with Lazy Initialization