Fat Controller CQRS Diet

Fat Controller CQRS DietI’ve been meaning to create a sample application that uses the MediatR library to dispatch command and queries.  All of this organizing and writing your code in vertical slices rather than layers.


I can only speak from my experiences and how I came to applying CQRS with mediator pattern.  Hopefully you can can relate and translate it to your own code base and determine if it is a right fit for you.

And that’s really important.  Is it a right fit for your application.

What this series will demonstrate is not to be used as silver bullet. Nor should it be used everywhere.

My intent with this series is to show how to use command and queries to decouple your application from you web framework.

And that’s exactly how I came to using command and queries.  By realizing I was building an application that was incredibly tied to my web framework.  I had little ability to take any code and easily move it around.

Fat Controller

Over time, my web application started to becoming was a collection of massive controllers.   They did everything from being HTTP endpoints, basic data validation, data access, business logic, authorization and probably had a pile more responsibilities.

Multiple Uses

As mentioned before with my fat controllers, I had no ability to reuse code in any meaningful way.  A lot of the code lived in controllers.  If by chance it wasn’t in a controller, it likely had some dependency on the MVC framework in some way.

Why is that problematic? Because I wanted to reuse some of these features in a new application that was being developed as a native Windows app.

Hiding Use Cases

I remember watching a video from Uncle Bob where he talked about how an MVC applications using a specific framework all looked the same and did not describe at all what the application did.

What were the actual uses cases?

What features did this application provide?

The project layout and structure were all the same. Two applications that provided completely different functionality but were structured and organized the same way.

This rang very true to me at the time.  I was hiding my uses cases by burying and coupling them to a web framework.

Music Store

Instead of writing an demo application from the ground up, I figured it would be a good idea to take an existing demo app and convert it using commands, queries and features slices.

I’m going to use the ASP.NET MusicStore sample application (.NET Core), since it has both a combination of HTML views and JSON endpoints.

If anyone has any other suggestions or recommendations to a different sample application to use, please leave comment or let me know on twitter.

DebuggerDisplay for Better Debugging

DebuggerDisplayJust wanted to make a quick post about a long forgotten friend the DebuggerDisplay attribute.

The DebuggerDisplayAttribute Class controls how an object, property, or field is displayed in the debugger variable windows. This attribute can be applied to types, delegates, properties, fields, and assemblies.

The DebuggerDisplay attribute has a single argument, which is a string to be displayed in the value column for instances of the type. This string can contain braces ({ and }). Text within a pair of braces is evaluated as a field, property or method.


So here I’m going to have a Person class.  I’m going to define the attribute to show the firstname and lastname.

Now when we debug, this is the result when we look at the new person instance.


Best Practice?

In most open source projects, it appears one of the practices many employ is creating an internal DebuggerDisplay that returns the relevant string you want to display.

Notice the “nq” in the DebuggerDisplay Attribute, this is to simply say “No Quotes”.  Here is the resulting output:



There are so many things like this attribute that either we just don’t know about or forget about along the way.  If you have any other suggestions please leave a comment here or on twitter.

Why use Nancy?

NancyFXOn one of my posts showing how you can use Nancy with ASP.NET Core, David Anderson posted the following comment

I came across some Nancy blogpost last week and got curious about it and so looked on internet for more information. I wanted to know why should someone use Nancy and why plain asp.net core is not sufficient. So far every place I look I see the same introduction, you know that one with ‘…super-duper-happy-path…’. But to be honest it’s still not clear ‘why’? What is it that someone can not do in ASP.NET Core which is ‘super-duper’ in Nancy? What is hard or missing in ASP.NET Core which is easy or available in Nancy? The need of such a framework on top of ASP.NET Core is very vage to me.

I realized that I never really blogged about why I started using Nancy.  I hinted at it slightly in my post about ASP.NET Core MVC Attribute Routing, but not in much detail.

MVC & Web API Routing

Like most, I primarily used ASP.NET MVC and Web API.  When I got into creating more Web API’s, the first thing that started causing me trouble was routing.

The convention based routing employed is to define your routes in the RouteCollection.  This is the familiar default route that you might have used before.

The primary issue I had with defining routes and route templates up front, was I to defined them closer to the code that was actually executing at a given endpoint.

Route Attributes do ultimately solve this problem and from what I’ve read recently, this seems to be the common way most now define routes.  However, I’m simply not a fan of attributes in this situation.  I won’t get into the reasons why, as I don’t think starting an attribute war serves much purpose for this post.

Nancy Routes

When I first seen how you defined routes in Nancy, I realized it was exactly what I was looking for.

Routes are defined in the constructor of a module. In order to define a route in Nancy, you need to specify a Method + Pattern + Action + (optional) Condition.

They’re just endpoints…

When you look at a Nancy module, you could compare it to a MVC or Web API Controller, but it’s really nothing more than a place you can define HTTP Endpoints.

This means you can use Modules as Controllers and develop using your familiar MVC pattern, or you could use them as Web API’s.  You can have your endpoint do whatever you need and return whatever you want.


Nancy by default is really simple to use.  You need zero configuration to get started.  Zero.

Add a Nancy Module and you are off to the races.

I’ve made a couple different posts on how you can use Nancy along side Web API in ASP.NET 4, and how you can use it with ASP.NET Core.


Back to the comment and the last sentence:

The need of such a framework on top of ASP.NET Core is very vage to me

Nancy doesn’t replaces ASP.NET Core, but it could replace your need for ASP.NET Core MVC.

With the application pipeline (middleware) in ASP.NET Core, this allows you to leverage many different components that serve different purposes all within your web application.

For example you could use Nancy, ASP.NET Core MVC, Static File Server and Authentication.

More Reasons

There are many more reasons and many considerations. I highly recommend reading a post by Jonathan Channon that covers different aspects.  The post that’s a tad old, but still very relevant.

I really enjoy the conversation I get in some of the comments.  Please leave a comment here or on twitter.