Tired of looking for errors in log files? Use OneTrueError - Automated exception management in .NET.

COM+ done right (refactoring a legacy application)

I’ve been spending a lot of time lately looking into a legacy application which uses COM+, i.e. got classes that inherits ServicedComponent. In this article I’ll show you some common mistakes and how you can correct them.

Continue reading

Posted in Architecture | Tagged | 2 Comments

Switched to disqus

I’ve switched from wordpress comment system to disqus. The old comments will hopefully get imported pretty soon.

Posted in Uncategorized | 2 Comments

Griffin.Decoupled: The queries

This article will show you how you can build your queries with the help of Griffin.Decoupled. Griffin.Decoupled is a small framework which helps you build applications with loose coupling which also can be scaled easily.

Continue reading

Posted in Architecture | Tagged , , | 5 Comments

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

Posted in Architecture | Tagged , , | 2 Comments

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.

Posted in Architecture | 7 Comments

Writing decoupled and scalable applications

Preface

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

Posted in Architecture | 6 Comments

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

Posted in Architecture, CodeProject | 12 Comments

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”

Why?

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.

Posted in Architecture, CodeProject | Tagged | 2 Comments

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

Posted in Architecture, CodeProject | Tagged | 12 Comments

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)

[TestClass]
public class WebClientTests
{
    [TestMethod]
    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));
        }

        Assert.IsFalse(result.Errors.Any());
    }
}

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

Implementation:

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()
    {
        File.Delete(FullPath);
    }

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

    public void Write(string text)
    {
        if (text == null) throw new ArgumentNullException("text");
        File.WriteAllText(FullPath, text);
    }
}
Posted in Uncategorized | Leave a comment