In my previous post, I explained how the Command in (our) CQRS implementation is just a DTO. This means we need to send it somewhere. Meet the CommandHandler. First, let’s define the interface. This will come in handy when we want to use dependency injection later. In my case, I injected the interface into my ASP.NET controllers so I could easily unit test them. The interface is simple: There’s not much to it, except for the fact that we only

Let’s start with the C in CQRS. As you know by now, the C is for “Command.” In our implementation of CQRS/ES, a command will be a basic DTO object. Later, we’ll see that CommandHandlers will take such a command and perform the necessary calls to domain objects. But let’s start simple. As stated, a command will be a simple DTO object, without any special logic. In my case, without any logic at all, except for a constructor. The name

CQRS (command and query responsibility segregation) and ES (event sourcing) are two patterns that are easily explained, but not so easily implemented. The patterns are gaining traction and often come together. But many developers have been trained in a classic CRUD way, and don’t always know where to begin. In this series, I’ll not only cover CQRS/ES abstractly, but I’ll provide real code examples to show you it’s really not very difficult. This first post will, however, focus on the

Note: I originally wrote this for SubMain. You can read the original here. Depending on your age and experience as a .NET developer, you might or might not be familiar with the technology known as Windows Forms. Windows Forms, or WinForms, was introduced together with .NET 1.0 in 2002. It was the first desktop UI technology for .NET. We’re now 16 (!) years later, and WinForms runs on the latest version of the .NET Framework (currently 4.7.2) and .NET Core

Note: I originally wrote this for SubMain. You can find the original here. In one of my previous posts, I wrote about the .NET build configuration system. I mentioned the app.config file, but didn’t really dive into it. So let’s take a closer look at this file now.¬†When you create a (non-web) .NET Framework application in Visual Studio, an app.config file is added to your project. When you create a class library or a .NET Core project, such a file

Editorial note: I originally wrote this for the NDepend blog. You can find the original here. Most people that start programming learn to program in an imperative way. Shortly after, they will probably learn a declarative language too. Many developers go a long way without knowing the difference. Many will probably never know. And they could very well be great developers. But knowing the difference could change the way you write code for the better, so let’s dive in. What

Editorial note: I originally wrote this post for ASPE. You can check out the original here, at their site. When developers use Git, they often use a combination of a graphical user interface and the command line. A GUI has a low barrier to entry, but many of us want to leverage the power that Git CLI. Once you’ve learned the basics of the Git command line, you have some powerful commands at your fingertips. And it only gets better

This is the third and final part in my short series on tackling legacy code. Previously, I wrote about general coding techniques, and about the organizational and operational requirements. I would like to close with some final thoughts. Technology isn’t the problem We developers can’t help but get enthusiastic about new technologies: languages, frameworks, libraries, techniques, etc. But more often than not, the problem with a legacy project is not the chosen technology or its age. Rather, it’s the way

In my previous post, I gave some insights into how you can start turning the legacy ship around. In the end, I talked about preconditions that should be fulfilled before you start. I’ll dive into those now. The organizational First and foremost, the organization must agree that tackling the legacy code is something they want to do. “The organization” can be defined on several levels: from the team to upper management. But the more support you have upwards, the better.

Legacy code is usually the code nobody likes to touch. It’s often complex, violates all kinds of best practices, has little or no tests, etc. Yet I find it very rewarding to work in legacy code. It takes a while, but when you start to tame that beast and understand its intricacies, it can actually be fun! But how do you start changing a legacy project, putting in modern standards, and making it maintainable? This article will explain some techniques