Introducing Griffin.Decoupled

I recommend that you read my other post first, since it describes the rationale behind Griffin.Decoupled. This post will only demonstrate how you use the framework.

Griffin.Decoupled allows you to execute commands and domain events within your application to reduce coupling between classes. In future versions you’ll also be able to scale out the application using different servers. And that without having to rewrite a single line of code. That’s one of the most important aspects of the framework: Start small and scale when required.

Continue reading “Introducing Griffin.Decoupled”

When is a logger a dependency?

There are some discussion about whether loggers should get injected into your classes (dependency injection) or if you should use the logger facade (like LogManager.GetLogger<MyClass>()).

The answer rather simple:

As for all classes, dependencies which is mandatory should get injected.

That means that you should inject the logger if the class will fail without it (= not deliver the expected result). If the class can work without a logger: simply use the logger facade.

Writing decoupled and scalable applications


This article is the first in a series of three articles. It’s purpose is only to introduce you do domain events and commands. The next article will show you how you with almost no effort (thanks to Griffin.Decoupled) can get started the command/event type of applications. The series will end with and article showing how you can use the DDD domain model together with the command and event handling.

Continue reading “Writing decoupled and scalable applications”

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);

Griffin.Container: Register services using your own attribute.

As you might now, I recommend that you register most classes using the [Component] attribute. However, you might not want to add an external dependency to all class libraries. You can avoid that now with a new feature. And that is to use your own attribute.

You can of course use the feature to customize the registration process. Let say that we’ve created a new attribute called ContainerServiceAttribute, so that we can decorate one of our classes:

public class SomeService

To register all classes with the new attribute use the following:

var registrar = new ContainerRegistrar(Lifetime.Transient);

// the new magic.

var container = registrar.Build();

The attribute itself is responsible of the registration. Here is a simplistic example:

class ContainerServiceAttribute : Attribute, IAttributeRegistrar
    public void Register(Type concrete, IContainerRegistrar registrar)
        //concrete = decorated class. In this case "SomeService"
        registrar.RegisterConcrete(concrete, Lifetime.Default);

Use the type to decide which interfaces etc that the class should be registered as.

The feature is available in version 1.0.3. Install it using nuget.

Code is available at github.

Resolving all services through dependency injection in Griffin.Container

I’ve just added a new feature to Griffin.Container: Support for resolving all implementations of a service by using constructors.

You can now do something like this:

public interface IStatefulService
	void Ping();

public class FtpConnection : IStatefulService

public class Pop3Connection : IStatefulService

public class ConnectionPinger
	public ConnectionPinger(IEnumerable<IStatefulService> services)
		_services = services;
	public void PingAll()
		_services.Each(x => x.Ping());

Griffin.Container can be found at github.