Find MediatR Requests without Handlers

Find MediatR Requests with no HandlersYou’ve run into it.  MediatR throwing an InvalidOperationException when you didn’t have a matching handler for a request.   There’s a fairly simple solution to prevent this: Find MediatR Requests without Handlers.

So here’s some quick code you can throw in a unit test to verify you don’t have any missing handlers.

Find MediatR Requests without Handlers

The above code uses reflection to get all the IRequest<>, RequestHandler<> and RequestHandler<,>.  Also worth mentioning it leverages Autofac for the IsClosedTypeOf method in the linq query.

Usage

Here’s a quick unit test that shows it’s usage for finding Requests without any handlers.  In the sample below I have two Requests without Handlers: MyRequestWithoutHandler and MyRequestWithResultWithoutHandler

Source

All the source code for my example is available on GitHub if you want to try it yourself.

Another useful test would be to verify that your container actually has the the request and behavior handlers registered correctly.  Another post to come with that.

Always love hearing your comments.  Please post them here or on Twitter.

 

Practical Microsoft Orleans

I’ve been wanting to take a deeper dive into Microsoft Orleans for awhile now.  With the next release targeting .NET Standard 2.0, it felt like an great time to do it.  This is the first blog post in a series that will go beyond a simple Hello World.  The plan is to make this a practical Microsoft Orleans guide to follow along with.

Blog Post Series:

Microsoft Orleans

If you aren’t familiar with Orleans, here’s a brief overview.

Orleans is a framework that provides a straightforward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns.

Or maybe you have heard Orleans is an Actor model framework.  Well…

Implementation of Orleans is based on the Actor Model that’s been around since 1970s. However, unlike actors in more traditional actor systems such as Erlang or Akka, Orleans Grains are virtual actors. The biggest difference is that physical instantiations of grains are completely abstracted away and are automatically managed by the Orleans runtime. The Virtual Actor Model is much more suitable for high-scale dynamic workloads like cloud services and is the major innovation of Orleans. You can read more details in the Technical Report on Orleans.

Docs

I have to give it to the Orleans team.  Their docs seem fantastic.  I’ve read over most of their Step-by-Step guide and feel like there’s a lot of insight being shared.  There’s a section about Concurrency that has some great code samples that gives with code samples a deadlock scenario.  I found reading over these docs to be really helpful in understanding and just looking at small code samples.

Event Sourcing

One aspect that I find interesting is having a grain manage it’s state being event sourced.

Event sourcing provides a flexible way to manage and persist grain state. An event-sourced grain has many potential advantages over a standard grain. For one, it can be used with many different storage provider configurations, and supports geo-replication across multiple clusters. Moreover, it cleanly separates the grain class from definitions of the grain state (represented by a grain state object) and grain updates (represented by event objects).

My plan is to use event sourcing as grain state and persist events to Event Store.  Luckily I’m familiar enough with Event Store however have to do more reading on if there is an existing implementation or have to roll my own.

Sample Application

As with other blog series I’ve done in the past, I find it helpful to take an existing OSS application that I can fork and use as a base.

Do you have a suggestion about an application I can fork to use as a base?  I’d love to hear your suggestions.  Let me know Twitter or in the comments.

Brighter MySQL Command Store

I’ve been wanting to explore Brighter for awhile, probably over a year.  I figured I’d try something new this time around and actually explore it by contributing to the project itself.  I noticed there were no Command and Message Stores yet supporting MySQL.  Turns out it was pretty straight forward to port the Sqlite Message & Command over to MySQL.  So that’s what I did, created a Brighter MySQL Command Store.

Brighter

First, if you’re unfamiliar with Brighter, here’s a quick description:

This project is a Command Processor & Dispatcher implementation that can be used as a lightweight library in other projects.

It can be used for implementing Ports and Adapters and CQRS (PDF) architectural styles in .NET.

In addition, Brighter supports Distributed Task Queues. As such it can be used to improve performance by introducing concurrency using a queue, and/or as an integration strategy between Microservices using messaging via a lightweight broker.

I like to think of Brighter as your possible next step from MediatR.  Since everything in MediatR is in process, which is great in many situations, it can also be less ideal in others.  When you need task queues, retry,  and circuit breaker type functionality is where Brighter can help right out of the box.

Command Sourcing

Don’t confuse Command Sourcing with Event Sourcing.  If you are, check out the Brighter docs that go into it a bit to clarify.

Any command dispatched with Brighter can be stored.  It’s actually pretty straightforward to setup.  I’m going to use the new MySqlCommandStore that I recently created as the example.

Register IAmCommandStore

First thing you need to do is register the MySqlCommandStore as a IAmACommandStore and/or IAmACommandStoreAsync, in the container you are using in your HandlerConfiguration.  Here’s a modified version of the HelloWorld sample.

For reference, the two parameters in the MySqlCommandStoreConfiguration are the connection string and the table name.

UseCommandSourcing Attribute

Second and last step is to add the UseCommandSourcing attribute to the command handler you want to persist into command store (MySQL table).

Result

When I run the sample app, here is the console output:

And the resulting record now stored in our MySQL database:

More

I plan on blogging more about Brighter in the near future.  Are you using Brighter?  Are there any specific features or topics you would like me to cover?  Let me know in the comments or on Twitter.