Conference Speaking Experience: CodeMash 2017

CodeMash 2017At some point in 2016 I decided I wanted to submit talks to a few large conferences.  I’ve done talks at various small user groups, but nothing more than 30 people.

The main reason to submit to larger conferences was just for the new experience.  It’s something that is completely out of my comfort zone to speak in front of a large group.

I really wanted to see if speaking at conferences was something I would enjoy or not.

Although I’ve realized that it’s really easy for me to talking about software and especially the areas that I’ve grown to enjoy.

CodeMash 2017

I submitted 3 talks for CodeMash 2017.  One of which was my talk “Fat Controller CQRS Diet“.  Here’s the abstract.

Do your controllers need to go on a diet?

Fat controllers can quickly lead to tight coupling by the abundance validation, business logic, and data access. Thin out your controllers by only using your web framework for what it’s good at: HTTP, Routing, and Serialization.

Attendees will learn to how to organize code by feature by leveraging CQRS and the Mediator pattern to decouple your core business capabilities from your web framework.

Once the call for speakers were starting to get announced, I received an email saying this talk submission was accepted.


At first it was pure excitement that one of my talks was accepted.

Once the initial surprise wore off, it turned to to pure confusion.  I couldn’t believe I actually submitted let alone was accepted.

I had 3 months to put together and prepare of my first conference talk.


My talk wasn’t really anything new to me.  My initial vision was really talking about my experiences and journey in writing various web apps my entire career.

Those experiences which led to me to current day of applying CQRS along with vertical feature slices.

I first worked through creating a slide deck that were just talking points initially.   I was constantly thinking about my talk and how I could build a story around the abstract.

User Group

I did a really rough version 1 of the talk at a local user group.  It was really more of a discussion than an actual talk.

But it gave me some great feedback about some of the rough ideas that I had going in.   I will definitely leverage doing this again as it was invaluable.


Once I took the feedback from the talk at the local user group, I started practicing the timing and length of the talk to the desired 50-60 minutes.  I did this by recording the talk along with slides on my machine.  I would painfully listen back and take notes about my pace, crutch words and any other hiccups.

More Feedback

Once I recorded and practiced enough where I wanted more feedback,  I did a final recording and sent it out to a few people.

They not only provided some real constructive feedback but also gave me a lot of confidence that my earlier practice was worth it.

Again, this feedback was really valuable and made its way as changes to my final talk.

It’s go time

I’m a pretty nervous and anxious person.  Anytime I have to do something out of my comfort zone, I get very nervous.

What’s really surprising to me, is although I was a bit anxious the couple days and hours leading up to my talk.  I was surprisingly not really nervous.

I was fairly calm.  I was confident because I knew I was prepared.

Overall I felt the talk went exactly as I had prepared.  The experience was something I really enjoyed.  I spoke with many attendees after the session to answer some other questions and go in a bit deeper.

Shout Out

A sincere thank you to the following for really helping me.

CodeMash for accepting and giving me the opportunity as a first time speaker.  And to all the attendees who packed the room!  This conference is so well put together and organized it blows my mind.  I would highly recommend attending this conference.   Easily the best conference I’ve been to.   The venue at the Kalahari is perfect. I brought my entire family with me and they had a blast at the Kalahari.

Reid Evans for taking the picture above during my talk and providing great feedback.

Joseph Woodward for helping and giving me feedback with my abstract.

Dave Rael and Shawn Rakowski for providing constructive and useful feedback that may its way into the final talk.


I love hearing your comments, questions and feedback!  Please post a comments or on Twitter.

MediatR Behaviors

MediatR BehaviorsI was happy and surprised to see that MediatR v3.0 was released yesterday.  One of the new features, which I was really looking forward to are pipeline behaviors.

A pipeline behavior is an implementation of IPipelineBehavior<TRequest, TResponse>. It represents a similar pattern to filters in ASP.NET MVC/Web API or pipeline behaviors in NServiceBus.


There are a couple major breaking changes to v3.  All of them I’m fairly happy about actually.


There is no distinction between sync, async (cancellable) requests or notifications.

You simply implement either IRequest or INotification.

You must still create the appropriate handler via either IRequestHandler, IAsyncRequestHandlerICancellableAsyncRequestHandler.


To send a request or publish a notification simply use Task Send(IRequest) or Task Publish(INotification)

No longer does it have the “Async” convention of appending to the method name.  I know this is often debated about this convention.  I don’t mind it at all since there are no sync methods.


The new addition is the interface IPipelineBehavior<TRequest, TResponse>

This allows you to create implementation(s) that will invoked in the order they are registered with your container (returned from the MultiInstanceFactory delegate).

The simplest implementation, that does nothing but call the next possible behavior.

You can see how you can use this to create Pre and Post behaviors to create a pipeline.

Pre & Post Processors

Thankfully, these have already been created and built-in to v3.

RequestPreProcessorBehavior<TRequest, TResponse> and RequestPostProcessorBehavior<TRequest, TResponse> to the rescue.

These can be used to implementing the appropriate interface of IRequestPreProcess<TRequest,TResponse> and IRequestPostProcessor<TRequest,TResponse>

Note: Be sure to register your  IRequestPreProcess<TRequest,TResponse> and IRequestPostProcessor<TRequest,TResponse> as well as RequestPreProcessorBehavior<TRequest, TResponse> and RequestPostProcessorBehavior<TRequest, TResponse>  with your container.

Test Drive

I figured I would use my ASP.NET Core MVC Music Store application as a test bed.

You can refer to my Fat Controller CQRS Diet: Command Pipeline post to see how created a pipeline in MediatR v2.  It involved creating wrapper/decorator with StructureMap.

This is incredibly straight forward and does all the heavy lifting that the pipeline decorator that I created previous.

For our MusicStore app, we can change our AddToCart for logging to be done like this.

The above code completely removed my need for my custom Pipeline decorator using StructureMap.  Win.

ASP.NET Extension

If you are using ASP.NET Core, check out the MediatR.Extensions.Microsoft.DependencyInjection v2.x package.  It has also been updated to support MediatR v3.

It adds several extension methods, one of which is IServiceCollection.AddMediatR(Assembly) to register all the Handlers and Pre/PostProcessor in a given assembly.


Are you using MediatR?  Do you plan on upgrading to v3?  I love hearing your comments, questions and recommendations!  Please post a comments or on Twitter.

Fat Controller CQRS Diet: Trade-offs

Trade-OffsIn my Fat Controller CQRS Diet series, I’ve shown the mediator pattern and the MediatR library. After a recent discussion with Reid Evans, he made me realize I haven’t really described the trade-offs.  This post is going to focus on trade-offs and an alternative to using the mediator pattern.

If you’re new to this series, here are earlier posts to get you up to speed:

  1. Overview of Series
  2. Simple Query
  3. Simple Command
  4. Command Pipeline
  5. Notifications
  6. Vertical Slices


With the mediator pattern, communication between objects is encapsulated with a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby lowering the coupling.

For me the purpose of using the mediator pattern is to limit the coupling between integration boundaries.  Those boundaries in my applications are typically the Web/UI Framework and my core application.

This means I’ll have my controllers take a dependency on the mediator and not my core application.

Runtime Resolution

The downside to this that there is no compile time type checking.  When the mediator is invoked at runtime, it could fail to send the request if there is no handler defined.

In the code example above, if there is no IAsyncRequestHandler<Home, List<Album>> then an exception will be thrown on _mediator.SendAsync(new Home());

Coupling to Handler (or Interface)

We could get around this and get our type checking at compile time by having the request handler injected into our controller.

This is fairly reasonable since I often have one controller per command or query.  This then limits the dependencies I’d be putting into the constructor.


One aspect that I haven’t touched on (yet) in this series is about background processing and queues.  I really enjoy using Hangfire to create background jobs.   I’ve blogged about it before and how to integrate MediatR and Hangfire together.

The general approach I take is to use messaging between MediatR and Hangfire to keep it consistent on how commands or queries are made.  That means messaging with MediatR done in-process or done on out of process (on other machines) via Hangfire but routing them through MediatR.



I love hearing your comments, questions and recommendations!  Please post a comments or on Twitter.