Skip to content

Validating Commands with the Decorator Pattern

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Validating CommandsThis post is how I have manged to handle validating commands and queries and belongs to a series about different aspects of applying CQRS Although these examples are demonstrating usage in commands, they are aslo applicable to queries. Examples are using using MediatR to handle our requests. If you are unfamiliar with CQRS or MediatR, here are some other relevant posts:

Feature

First let’s take a look at our feature for Changing a Customers Pricing Level.  In this example I’ve organized all aspects of this feature into one file.  This single file contains our NancyFX Module and Route, Command and Command Handler.

Validation

One small piece of validation I would like to add, is validating the CustomerId is not an empty Guid. When deserialization occurs thru the Bind() method, if the CustomerId is not present in the payload, the CustomerId will be an empty Guid (00000000-0000-0000-0000-000000000000). The simplest approach is to add the validation to our Handler.
This doesn’t look incredibly horrible, however we are violating SRP and as you develop more complex commands, validating them will start to consume your Handler.

Decorator Pattern

In object-oriented programming, the decorator pattern (also known as Wrapper, an alternative naming shared with the Adapter pattern) is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.[1] The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern.[2]
The decorator pattern is pretty straight forward, and even if you never knew the term, you likely already used it. Here is our decorator for wrapping the command handler with our new validation handler.

Validation Handler

Now we can extract our validation logic out of our command handler and add it to a validation handler which will be invoked prior to the command handler.

Invoking

The one piece of the puzzle that I can’t show exactly in this example will be dependent on what container you use.  When you create a new instance of MediatR you provide a single and multi instance factory in the constructor.  Generally this will be your preferred container.   Check out our container docs to see how you register a decorator.

Comments

I’d love to hear how you handle command or query validation.  Please share in the comments below or on twitter.

Related Posts

5 thoughts on “Validating Commands with the Decorator Pattern”

  1. Pingback: The Morning Brew #2075 | Tech News

  2. Specifically in Nancy, you don’t need that 🙂 . Nancy already has a `Validate / BindToAndValidate` method which invokes the validator configured for a model. With FluentValidation you just create the validator class and that’s it.

  3. Pingback: Ah, I like that. I like links. links is much better than mongoloid. - Fabienne Coolidge - Magnus Udbjørg

Leave a Reply

Your email address will not be published. Required fields are marked *