Service locator is not an anti pattern.

(this article have been rewritten since it didn’t seem like I managed to communicate my thoughts properly)

There are several blog posts that states that service locator is an anti pattern. With this article I’ll try to explain why it’s not. Do understand that I’m not saying that it should be used for dependency management.

Continue reading “Service locator is not an anti pattern.”

Dealing with exceptions, Logging and displaying error messages

I got a client which is really firm on that the user should know what went wrong when exceptions are thrown. So we are displaying error messages like

“The database did not respond”
“The database operation failed”
“Failed to load configuration setting X”

etc etc.

If it were just me, I would simply just print something like:

“Oops, something unexpected happened. Please try again or contact the support department”


Ok. So let’s assume that we show the user a more detailed error message. What is he/she supposed to do with it? Remember, it’s from an exception. If something exceptional happens it unlikely that the user can fix the problem by reading an error message. At tops the user can try do perform the operation again.

When the user have got tired of trying he/she calls the support department. If we’re lucky the user manages to quote the error message exactly. But really. Do that help us? Not really. We still have to go through our logs to find out what happened.

The correct approach to dealing with exceptions

So what should we do when an exception happens? Well. Try to prevent it from happening in the future. That goes for all exceptions. Some can be prevented, whilst others can’t. The point is that we should at least try.

To be able to try to fix the exceptions we have to find them. Using a big fat log for everything is not a very good way. Instead try to have a seperate log for all unhandled exceptions. Make sure that you read that log. You might want to build something that emails that log to you daily.

Why Domain Driven Design (DDD) is so great

This article aims to describe why I think that DDD aids you tremendously in creating robust and flexible applications.

Today we got several cool frameworks and libraries that we can use. ORMs, WCF, ServiceStack, SignalR, WebApi, IoC etc etc. Just thinking of all can make any serious developer go crazy of joy.

Continue reading “Why Domain Driven Design (DDD) is so great”

Small temp file helper for integration tests

I’m writing some integration tests and needed to be able to create/cleanup temp files during the test. So I’ve created a small helper for that (so that the file will be deleted even if the test fails)

public class WebClientTests
    public void Upload()
        var subject = new EfecteWebClient(new HardCodedConfig());
        var repos = new ChangeRequestRepository(subject);
        var changeRequest = repos.Get("ACHG-00002978");

        UploadResult result;
        using (var tempFile = new TempFile("Hello world"))
            var stream = new FileStream(tempFile.FullPath, FileMode.Open);
            result = subject.Upload(() => changeRequest.Title, UploadType.Set, new HttpFile("myFile", "mydocument.txt", stream));


See? the tempfile class implements IDisposable so that the tests won’t be cluttered with the cleanup.


public class TempFile : IDisposable
    public TempFile()

    public TempFile(string contents)
        if (contents == null) throw new ArgumentNullException("contents");
        FullPath = Path.GetTempFileName();
        File.WriteAllText(FullPath, contents);

    public string FullPath { get; private set; }

    public void Dispose()

    public string Read()
        return File.ReadAllText(FullPath);

    public void Write(string text)
        if (text == null) throw new ArgumentNullException("text");
        File.WriteAllText(FullPath, text);