<p>There are many solutions on the market (including <a href="https://github.com/zeromq/netmq">free</a> <a href="https://github.com/pardahlman/RawRabbit">open</a> <a href="https://www.rabbitmq.com/dotnet.html">source</a>) for creating both message queues and event buses. However, for example purposes - and as a simple <em>proof of concept</em> - I just wanted a simple way to store the contents of a <code>Command</code>, run the <code>CommandHandler</code>, receive <code>Event</code> objects, call the <code>EventHandler</code> actions, and save all of the results. Everything runs synchronously and there are no retry policies, topics, or request/reply patterns. It is a simple, nearly useless set of code - but it serves its very specific purpose.</p>
<h2>SqlCommandQueue</h2>
<p>Calling this a "queue" is a complete misnomer, since there is no actual queuing of the commands. All this does is persist the command to the database, call the command handler, and then declare the command as handled.</p>
<pre><code>using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using System;
using Vigil.Domain.Messaging;

namespace Vigil.Sql
{
    public class SqlCommandQueue : ICommandQueue
    {
        private readonly IServiceProvider _serviceProvider;
        private readonly Func&#x3C;SqlMessageDbContext> _dbFactory;

        public SqlCommandQueue(IServiceProvider serviceProvider,
            Func&#x3C;SqlMessageDbContext> dbFactory)
        {
            _serviceProvider = serviceProvider;
            _dbFactory = dbFactory;
        }

        public void Publish&#x3C;TCommand>(TCommand command) where TCommand : ICommand
        {
            using (SqlMessageDbContext context = _dbFactory())
            {
                var newCmd = new Command()
                {
                    GeneratedBy = command.GeneratedBy,
                    GeneratedOn = command.GeneratedOn,
                    Id = command.Id,
                    SerializedCommand = JsonConvert.SerializeObject(command),
                    CommandType = typeof(TCommand).AssemblyQualifiedName,
                    DispatchedOn = DateTime.UtcNow
                };
                context.Commands.Add(newCmd);
                context.SaveChanges();
            }

            var handler = _serviceProvider
                .GetRequiredService&#x3C;ICommandHandler&#x3C;TCommand>>();
            handler.Handle(command);

            using (SqlMessageDbContext context = _dbFactory())
            {
                var cmd = context.Commands.Find(command.Id);
                cmd.HandledOn = DateTime.UtcNow;
                context.SaveChanges();
            }
        }
    }
}
</code></pre>
<p>A bit of magic happens on lines 28 and 29 — in order to retrieve an arbitrary object for later consumption, the command needs to be serialized. Additionally, to allow it to be deserialized later, the full AQN of the class should be kept handy. The actual work is done in lines 36 and 37, which get the command handler that has already been globally registered, and then calls the <code>Handle</code> method. Since nothing happens asynchronously, the queue is fully able to assume that returning control back to it means the command has been handled. Updating the <code>HandleOn</code> property closes that loop.</p>
<h2>SqlEventBus</h2>
<p>Just as the "Command Queue" isn't a queue, the <code>SqlEventBus</code> isn't a bus, or a topic, or any kind of fancy messaging. What does it do? It persists the event to storage (a database), gets and calls all of the event handlers, then marks the persisted event as handled. The code looks quite similar to the <code>SqlCommandQueue</code>.</p>
<pre><code>using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using System;
using Vigil.Domain.Messaging;

namespace Vigil.Sql
{
    public class SqlEventBus : IEventBus
    {
        private readonly IServiceProvider _serviceProvider;
        private readonly Func&#x3C;SqlMessageDbContext> _dbFactory;


        public SqlEventBus(IServiceProvider serviceProvider,
            Func&#x3C;SqlMessageDbContext> dbFactory)
        {
            _serviceProvider = serviceProvider;
            _dbFactory = dbFactory;
        }

        public void Publish&#x3C;TEvent>(TEvent evnt) where TEvent : IEvent
        {
            using (SqlMessageDbContext context = _dbFactory())
            {
                var newEvnt = new Event()
                {
                    GeneratedBy = evnt.GeneratedBy,
                    GeneratedOn = evnt.GeneratedOn,
                    Id = evnt.Id,
                    SourceId = evnt.SourceId,
                    EventType = typeof(TEvent).AssemblyQualifiedName,
                    SerializedEvent = JsonConvert.SerializeObject(evnt),
                    DispatchedOn = DateTime.UtcNow
                };
                context.Events.Add(newEvnt);
                context.SaveChanges();
            }

            var handlers = _serviceProvider.GetServices&#x3C;IEventHandler&#x3C;TEvent>>();
            foreach(IEventHandler&#x3C;TEvent> handler in handlers)
            {
                handler.Handle(evnt);
            }

            using (SqlMessageDbContext context = _dbFactory())
            {
                var handled = context.Events.Find(evnt.Id);
                handled.HandledOn = DateTime.UtcNow;
                context.SaveChanges();
            }
        }
    }
}
</code></pre>
<p>The unit tests are very simple (so simple that I haven't even created them - and probably won't). It would just be a set of tests that verify it is doing exactly what I've told it to do. Since this code is only a demostration, and not meant for any kind of actual use, I'm not bother to fully unit test it. I doubt that this code will survive past the point where I have a real queue and bus living up in Azure.</p>
<p>Two other pieces that I did add, that may be something that carries into an Azure implementation. I created new <code>Command</code> and <code>Event</code> objects that are just POCO wrappers for the <code>Vigil.Domain.Command</code> and <code>Vigil.Domain.Event</code> entities that are being persisted. One little handy thing that I did create, solely for debugging, is a <code>SqlViewerController</code> that sets up a <em>/sql/</em> route with a way to view all persisted commands, all persisted events, and the ability to test rehydrating a <code>Patron</code>. It has been useful to have when I was testing out the <code>Vigil.WebApi</code> project — more on that in another post.</p>


Illusions of Queues and Buses

<p>There are two ways to retrieve the current values associated with an entity. The canonical source is the collection of events that describe how an entity came into existance and then was affected over time. The standard term for this seems to be "hydrating" the entity. Once the current state of the entity is found, it can then be persisted to a different medium for easier access. In the example of a <code>Patron</code>, there are few circumstances where the entire history of the entity is needed. Instead, most requests for the information will only be looking for the most current iteration - which is found in a snapshot database. One of the first challenges that I faced when building this initial prototype was proving that my code could rehydrate a <code>Patron</code> from only a list of events.</p>
<p>Looking into the details of what the process is when hydrating a <code>Patron</code>, the best place to start is with the constructor. The prelude to calling the constructor, of course, is that something has gone and fetched a collection of <code>IVersionedEvent</code> entities with a given <code>PatronId</code>.</p>
<pre><code>using System;
using System.Collections.Generic;
using Vigil.Domain.EventSourcing;
using Vigil.Patrons.Events;

public class Patron : EventSourced
{
    public Patron(Guid patronId, IEnumerable&#x3C;IVersionedEvent> history) : this(patronId)
    {
        LoadFrom(history);
    }

    protected Patron(Guid patronId) : base(patronId)
    {
        Handles&#x3C;PatronCreated>(OnPatronCreated);
        Handles&#x3C;PatronHeaderChanged>(OnPatronHeaderChanged);
        Handles&#x3C;PatronDeleted>(OnPatronDeleted);
    }
}

public abstract class EventSourced : IEventSourced
{
    private readonly Dictionary&#x3C;Type, Action&#x3C;IVersionedEvent>> handlers
        = new Dictionary&#x3C;Type, Action&#x3C;IVersionedEvent>>();

    protected void LoadFrom(IEnumerable&#x3C;IVersionedEvent> pastEvents)
    {
        var orderedPastEvents = pastEvents.OrderBy(pe => pe.GeneratedOn);
        foreach (var e in orderedPastEvents)
        {
            handlers[e.GetType()].Invoke(e);
            Version = e.Version;
            events.Add(e);
        }
    }
}

</code></pre>
<p>I saw two options for where to put the actions that receive an event and cause an entity to be in the proper state. Either I could create an <code>EventHandler</code> that receives an entity and then conjures up a new instance of it with the resultant changes (thus making entities immutable), or I could have an entity know how to handle events that affect it (entities are thus mutable objects).</p>
<p>I liked the idea of keeping the logic of how an <code>EventSourced</code> object is affect consolidated to just the entity itself. This allows for an ORM (like <a href="https://docs.microsoft.com/en-us/ef/">Entity Framework</a>) to directly assign data to the entity's properties, or for something else that has the collection of events to tell an entity to just <em>create itself</em>. Thus, the <code>Patron</code> constructor defines all of the events that it knows how to handle. When constructed with a collection of <code>IVersionEvent</code> objects, it calls the inherited <code>LoadFrom</code> method from <code>EventSourced</code>. My assumption is that the unit tests will be written to ensure that the <code>Patron</code> registers only events that are useful and that it handles all of the events that it should.</p>
<p>My initial goal was to create some sort of reflection assembly scanning that would find all methods that match the signature needed for an event and allow them to self-register. I might be able to create a custom attribute for that - perhaps a <code>HandlesEventAttribute</code>.</p>
<p>Anyway, each of the events, in creation order, get their appropriate method within the <code>Patron</code> object invoked, which updates the properties as appropriate. Unit testing is fairly straightforward.</p>
<pre><code>using System;
using Vigil.Domain.EventSourcing;
using Vigil.Patrons.Events;
using Xunit;

namespace Vigil.Patrons
{
    public class PatronTest
    {
        [Fact]
        public void Patron_Can_Be_Hydrated_From_Patron_Created()
        {
            var patronId = Guid.NewGuid();

            PatronCreated created = new PatronCreated("Create User", TestHelper.Now, Guid.NewGuid())
            {
                DisplayName = "Test Creation",
                IsAnonymous = false,
                PatronType = "Test Account",
                PatronId = patronId,
                Version = 0
            };
            Patron result = new Patron(patronId, new[] { created });

            Assert.Equal("Test Creation", result.DisplayName);
            Assert.False(result.IsAnonymous);
            Assert.Equal("Test Account", result.PatronType);
            Assert.Equal(patronId, result.Id);
            Assert.Equal(0, result.Version);
            Assert.Equal("Create User", result.CreatedBy);
            Assert.Equal(TestHelper.Now, result.CreatedOn);
            Assert.Null(result.ModifiedBy);
            Assert.Null(result.ModifiedOn);
            Assert.Null(result.DeletedBy);
            Assert.Null(result.DeletedOn);
        }

        [Fact]
        public void Patron_Can_Be_Hydrated_From_Patron_Created_And_Updated()
        {
            var patronId = Guid.NewGuid();
            var evnts = new VersionedEvent[] {
                new PatronCreated("Create User", TestHelper.Now, Guid.NewGuid())
                {
                    DisplayName = "Test Creation",
                    IsAnonymous = false,
                    PatronType = "Test Account",
                    PatronId = patronId,
                    Version = 0
                },
                new PatronHeaderChanged("Change User", TestHelper.Later, Guid.NewGuid())
                {
                    DisplayName = "Test Update",
                    IsAnonymous = true,
                    PatronType = "Test Updated",
                    PatronId = patronId,
                    Version = 1
                }
            };
            Patron result = new Patron(patronId, evnts);

            Assert.Equal("Test Update", result.DisplayName);
            Assert.True(result.IsAnonymous);
            Assert.Equal("Test Updated", result.PatronType);
            Assert.Equal(patronId, result.Id);
            Assert.Equal(1, result.Version);
            Assert.Equal("Create User", result.CreatedBy);
            Assert.Equal(TestHelper.Now, result.CreatedOn);
            Assert.Equal("Change User", result.ModifiedBy);
            Assert.Equal(TestHelper.Later, result.ModifiedOn);
            Assert.Null(result.DeletedBy);
            Assert.Null(result.DeletedOn);
        }

        [Fact]
        public void Patron_Can_Be_Hydrated_From_Patron_Created_And_Empty_Updated()
        {
            var patronId = Guid.NewGuid();
            var evnts = new VersionedEvent[] {
                new PatronCreated("Create User", TestHelper.Now, Guid.NewGuid())
                {
                    DisplayName = "Test Creation",
                    IsAnonymous = false,
                    PatronType = "Test Account",
                    PatronId = patronId,
                    Version = 0
                },
                new PatronHeaderChanged("Change User", TestHelper.Later, Guid.NewGuid())
                {
                    PatronId = patronId,
                    Version = 1
                }
            };
            Patron result = new Patron(patronId, evnts);

            Assert.Equal("Test Creation", result.DisplayName);
            Assert.False(result.IsAnonymous);
            Assert.Equal("Test Account", result.PatronType);
            Assert.Equal(patronId, result.Id);
            Assert.Equal(1, result.Version);
            Assert.Equal("Create User", result.CreatedBy);
            Assert.Equal(TestHelper.Now, result.CreatedOn);
            Assert.Equal("Change User", result.ModifiedBy);
            Assert.Equal(TestHelper.Later, result.ModifiedOn);
            Assert.Null(result.DeletedBy);
            Assert.Null(result.DeletedOn);
        }

        [Fact]
        public void Patron_Can_Be_Hydrated_From_Patron_Created_And_Deleted()
        {
            var patronId = Guid.NewGuid();
            var evnts = new VersionedEvent[] {
                new PatronCreated("Create User", TestHelper.Now, Guid.NewGuid())
                {
                    DisplayName = "Test Creation",
                    IsAnonymous = false,
                    PatronType = "Test Account",
                    PatronId = patronId,
                    Version = 0
                },
                new PatronDeleted("Delete User", TestHelper.Later, Guid.NewGuid())
                {
                    PatronId = patronId,
                    Version = 1
                }
            };
            Patron result = new Patron(patronId, evnts);

            Assert.Equal("Test Creation", result.DisplayName);
            Assert.False(result.IsAnonymous);
            Assert.Equal(patronId, result.Id);
            Assert.Equal(1, result.Version);
            Assert.Equal("Create User", result.CreatedBy);
            Assert.Equal(TestHelper.Now, result.CreatedOn);
            Assert.Equal("Delete User", result.ModifiedBy);
            Assert.Equal("Delete User", result.DeletedBy);
            Assert.Equal(TestHelper.Later, result.ModifiedOn);
            Assert.Equal(TestHelper.Later, result.DeletedOn);
        }
    }
}
</code></pre>


Hydrating A Patron

<p>2016 was a busy year - in total, I ran eight races. While four of them were all in one weekend for <a href="/posts/2016/disney-s-dopey-challenge/">Disney's Dopey Challenge</a>, it was still a lot of early mornings for me. For 2017, I am going to scale things back a bit - which really just means removing the one racing weekend.</p>
<h2>F3 Half Marathon</h2>
<p>My favorite half marathon in Chicago is the <a href="http://www.f3running.com/">F^3 Lake Half Marathon</a>. My current personal record for a half marathon is 1:36:44, coming from last year's race. I enjoy the race because it is small enough that I feel competative, but it is large enough that the course does not feel empty. My first goal is to clear 1:35:00, with a rocket goal of finishing under 1:30:00 (6:51/mile). Ninty minutes to run 31.1 miles. Just thinking about it makes me think I might be approaching an acceptable pace to be called fast. This race is heavily weather dependent; if winds are calm and the course is dry, then I expect good things.</p>
<h2>Kalamazoo Marathon</h2>
<p>I have been doing a different spring marathon each year for the past two years - <a href="/posts/2015/3-56-58-2015-wisconsin-marathon/">Wisconsin</a> and <a href="https://results.chronotrack.com/event/results/event/event-13270?entryID=16657247">New Jersey</a>. In the spirit of trying something new, I'll be heading to Michigan for this year's spring marathon, running the <a href="https://thekalamazoomarathon.com/">Kalamazoo Marathon at the Borgess Run</a>. My goal is to finish under 3:15:00 (7:26/mile); which, conveniently, is also the fastest pace group that the race offers. My goal is to hold tight with them for as long as I can. If I am feeling really good after 18 miles, then I might try to go ahead of them. Otherwise, I will be thoroughly thrilled with crossing with the group. As with all of my races, the minimum goal for me is to beat my PR of 3:21:43.</p>
<h2>Some Unnamed 5k</h2>
<p>For the past four years, I have run the <a href="http://www.universalsole.com/burgers--beer-5k.html">Burgers &#x26; Beer 5k</a>. I am undecided if I want to run that race again, or find some other 5k. Last year, I was doing a #Whole30, so I couldn't eat the burger or the beer. It lost a lot of the luster. I would be willing to do it again, if I knew that I would not be on a restricted diet on race day. Otherwise, I will run one of the many other 5k races the city has during the summer. My options are not slim. My goal would be to beat my PR - 19:21 (6:13/mile).</p>
<h2>Chicago Marathon 2017</h2>
<p>This will be my fifth Chicago Marathon in a row, and if all goes well, will be the race that I finally qualify for the Boston Marathon - thus running that race in April 2019. Since I would be 37 on race day, my qualifying standard is 3:10:00; but with the way they do actual selection, I am aiming for 3:05:00 (7:03/mile). Five full minutes under the standard should be plenty to clear selection cutoffs.</p>


My 2017 Running Calendar

<p>I have come to the point where I am building out the initial proof-of-concept for the WebAPI portion of this project. This gives me a place to continue testing out features, and see if how I envisioned things would work can actually work. One of the first parts of unit testing the controller was to mock any of the properties that I need to use that the web server would ordinarily wire up. In a <code>Controller</code> that primarily entails the <code>ControllerContext</code>, which would also wire the <code>Controller.User</code>, <code>Controller.Url</code>, and <code>Controller.HttpContext</code> properties. So how do I do that?</p>
<h3>Mocking Controller.Url</h3>
<p>I use Moq as my mocking framework, though this could be done with any library. The <code>Url</code> property returns an <code>IUrlHelper</code>, which makes it easy to mock.</p>
<pre><code>namespace Microsoft.AspNetCore.Mvc
{
    public interface IUrlHelper
    {
        ActionContext ActionContext { get; }

        string Action(UrlActionContext actionContext);
        string Content(string contentPath);
        bool IsLocalUrl(string url);
        string Link(string routeName, object values);
        string RouteUrl(UrlRouteContext routeContext);
    }
}
</code></pre>
<p>The <code>Content(string)</code>, <code>IsLocalUrl(string)</code>, and <code>Link(string, object)</code> are all trivial to overload. The piece that I stumbled across was when I wanted to mock <code>Url.Action(string, object)</code>, which is an extension method in the <code>UrlHelperExtensions</code> class. Moq is unable to mock extension methods. However, because <code>AspNetCore</code> is open source, I could happily go <a href="https://github.com/aspnet/Mvc/blob/master/src/Microsoft.AspNetCore.Mvc.Core/UrlHelperExtensions.cs">look at the source</a> and see what the extension method was doing behind the scenes. All of the various extension methods just pass controll to the last (and longest) extension method, which calls <code>Url.Action(UrlActionContext)</code>. They all pass a <code>null</code> for values not collected.</p>
<pre><code>public static string Action(
    this IUrlHelper helper,
    string action,
    string controller,
    object values,
    string protocol,
    string host,
    string fragment)
{
    if (helper == null)
    {
        throw new ArgumentNullException(nameof(helper));
    }

    return helper.Action(new UrlActionContext()
    {
        Action = action,
        Controller = controller,
        Host = host,
        Values = values,
        Protocol = protocol,
        Fragment = fragment
    });
}

</code></pre>
<p>This all means that in order to "mock" the extension methods, I just need to provide a mock for the <code>IUrlHelper.Action(UrlActionContext)</code> method.</p>
<pre><code>[Fact]
public void Create_With_ValidCommand_IsPublished_AndReturnsAcceptedResult_WithLocation()
{
    CreatePatron cmd = new CreatePatron("Patron Web Test", TestHelper.Now)
    {
        DisplayName = "Patron Display Name",
        IsAnonymous = false,
        PatronType = "Test Patron"
    };

    var mockUrlHelper = new Mock&#x3C;IUrlHelper>(MockBehavior.Strict);
    Expression&#x3C;Func&#x3C;IUrlHelper, string>> urlSetup
        = url => url.Action(It.Is&#x3C;UrlActionContext>(uac => uac.Action == "Get" &#x26;&#x26; GetId(uac.Values) != cmd.Id));
    mockUrlHelper.Setup(urlSetup).Returns("a/mock/url/for/testing").Verifiable();

    var controller = new PatronController()
    {
        Url = mockUrlHelper.Object
    };

    AcceptedResult result = controller.Create(cmd) as AcceptedResult;

    Assert.NotNull(result);
    mockUrlHelper.Verify(urlSetup, Times.Once());
    Assert.Equal("a/mock/url/for/testing", result.Location);
}

private Guid? GetId(object values)
{
    return values?.GetType().GetProperty("id")?.GetValue(values, null) as Guid?;
}
</code></pre>
<p>On my initial attempt, I was having the Url mock return an actual Url. However, I realized that since the string that returns from this shouldn't have any effect other than being a string, it <em>should</em> be some meaningless value. This code is not attempting to mock the routing or url creation based on the values sent to the <code>IUrlHelper</code>. All this unit test is doing, and all it <em>should be doning</em>, is validating that the controller is asking for a string that comes from passing in the "Get" action and an object with a property of "id" that is a <code>Guid</code>.</p>
<p>Mocking the <code>UrlHelperExtensions.RouteUrl(this IUrlHelper, ...)</code> extension methods is done the same way, but by mocking the <code>IUrlHelper.RouteUrl(UrlRouteContext)</code> method. The <code>RouteUrl</code> extension methods also just pass along their values to a new instance of <code>UrlRouteContext</code> and then call the interface's method.</p>
<h2>Mocking Controller.User.Identity.Name</h2>
<p>Mocking the User property on a Controller can be a little more difficult to figure out, because the <code>ControllerBase.User</code> property is read-only; <code>User</code> gets its value from the <code>HttpContext.User</code> property. The <code>Request</code> and <code>Response</code> properties on the <code>ControllerBase</code> also come from the <code>HttpContext</code>. Fortuitously, <code>ControllerBase.HttpContext</code> is settable and <code>HttpContext</code> is an abstract class. Therefore, a simple stub of the <code>User</code> property on a mock of the <code>HttpContext</code> takes care of whatever needs there are for accessing the claims information.</p>
<p>Since the most common usage for this is that I am trying to access the user's name, I created a quick private method that goes inside of my test class. Moq takes care of walking the expression tree and creating the necessary mocks of the <code>ClaimsPrincipal</code> and the <code>IIdentity</code> properties.</p>
<pre><code>private void SetupUser(Controller controller, string username)
{
    var mockContext = new Mock&#x3C;HttpContext>(MockBehavior.Strict);
    mockContext.SetupGet(hc => hc.User.Identity.Name).Returns(username);
    controller.ControllerContext = new ControllerContext()
    {
        HttpContext = mockContext.Object
    };
}
</code></pre>


Mock Controller's User and Url Properties in ASP.NET Core MVC

<p>Now that I have revised my approach for what constitutes <a href="/posts/2016/revisiting-creating-and-updating-entities/">creating and updating entities</a>, I am going back to my <code>Patron</code> entity to rework the create and update commands. I have already scrapped the <code>Factory</code> class and its associated unit tests, and gone forward with code creation.</p>
<h2>Commands for Create and Update Patron</h2>
<p>The first major change is that I have moved the Patron Commands into the <code>Vigil.Patrons</code> project; at this moment, I am keeping projects confined by domain. Later, I may find this to be in error, but for now it seems to make sense. I am keeping validation on the Command class and the unit tests for the validation scenarios does not need to change at all. The only change that I made was adding the <code>Id</code> property implementation for <code>ICommand</code>. Since I would like to track every part of the system, it makes sense to have unique identifiers for everything.</p>
<pre><code>using System;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using Vigil.Domain.Messaging;

namespace Vigil.Patrons.Commands
{
    public class CreatePatronCommand : ICommand
    {
        public Guid Id { get; set; } = Guid.NewGuid();

        [Required, StringLength(250)]
        public string DisplayName { get; set; }
        [DefaultValue(false)]
        public bool IsAnonymous { get; set; } = false;
        [Required, StringLength(250)]
        public string PatronType { get; set; }
    }
}
</code></pre>
<p>Along with some other shuffling around, I have dropped the notion of passing around <code>IKeyIdentity</code> and just using the <code>Guid</code>. I am never going to change the type of the key; but if I did, it would need to be a momumental undertaking anyway, since I would be changing <em>everything</em>. <code>Guid</code> is universally understood and unique, so I am just making life easier that way.</p>
<pre><code>using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using Vigil.Domain.Messaging;

namespace Vigil.Patrons.Commands
{
    public class UpdatePatronCommand : ICommand, IValidatableObject
    {
        public Guid Id { get; set; } = Guid.NewGuid();

        public Guid PatronId { get; set; }

        [StringLength(250)]
        public string DisplayName { get; set; }
        public bool? IsAnonymous { get; set; }
        [StringLength(250)]
        public string PatronType { get; set; }

        public IEnumerable&#x3C;ValidationResult> Validate(ValidationContext validationContext)
        {
            if (PatronId == Guid.Empty)
            {
                yield return new ValidationResult("PatronId is a required field.", new string[] { nameof(PatronId) });
            }
        }
    }
}
</code></pre>
<h2>Patron Command Handler</h2>
<p>Someone else will put a command in a message queue, and some other process will handle pulling that command off of the queue and instantiating the <code>PatronCommandHandler</code>. However, once all that work is taken care of (it's all part of the unit test's arrange step), it is time to turn the command into a series of events. While the current examples only show one event fired from the command, there could be many more. However, there are two (probably hard and fast) rules: #1 - there must be exactly one command handler per command (though one handler can handle many different commands), and #2 - every command must fire at least one event (if a command doesn't create an event, what's the point?).</p>
<pre><code>using System;
using Vigil.Domain.Messaging;
using Vigil.Patrons.Commands;
using Vigil.Patrons.Events;

namespace Vigil.Patrons
{
    public class PatronCommandHandler : ICommandHandler&#x3C;CreatePatronCommand>
    {
        private readonly IEventBus eventBus;
        private readonly ICommandRepository repo;

        public PatronCommandHandler(IEventBus eventBus, ICommandRepository repo)
        {
            this.eventBus = eventBus;
            this.repo = repo;
        }

        public void Handle(CreatePatronCommand command)
        {
            var patronCreated = new PatronCreated
            {
                SourceId = command.Id,
                PatronId = Guid.NewGuid(),
                DisplayName = command.DisplayName,
                IsAnonymous = command.IsAnonymous,
                PatronType = command.PatronType
            };
            eventBus.Publish(patronCreated);
            repo.Save(command);
        }

        public void Handle(UpdatePatronCommand command)
        {
            var patronUpdated = new PatronUpdated
            {
                SourceId = command.Id,
                PatronId = command.PatronId,
                DisplayName = command.DisplayName,
                IsAnonymous = command.IsAnonymous,
                PatronType = command.PatronType
            };
            eventBus.Publish(patronUpdated);
            repo.Save(command);
        }
    }
}
</code></pre>
<h2>Command Handler Unit Tests</h2>
<p>The purpose of a unit test for an <code>ICommandHandler</code> is to ensure the correct event(s) is/are put on the event bus, and that the command will be persisted through the repository. Later unit tests on the repository itself will determine if the entity was actually persisted, and later tests on the actual implementation of the event bus will determine if anything happens when an event is put on the bus. But for this unit test, the code is just checking to make sure the handler does what is expected.</p>
<pre><code>using Moq;
using System;
using Vigil.Domain.Messaging;
using Vigil.Patrons.Commands;
using Vigil.Patrons.Events;
using Xunit;

namespace Vigil.Patrons
{
    public class PatronCommandHandlerTest
    {
        [Fact]
        public void User_Can_Create_New_Patron()
        {
            CreatePatronCommand command = new CreatePatronCommand()
            {
                DisplayName = "Test Patron",
                IsAnonymous = false,
                PatronType = "Test Account"
            };

            var eventBus = new Mock&#x3C;IEventBus>();
            eventBus.Setup(bus => bus.Publish(It.IsAny&#x3C;PatronCreated>()))
                .Callback&#x3C;PatronCreated>((@event) =>
                {
                    Assert.Equal(command.DisplayName, @event.DisplayName);
                    Assert.Equal(command.IsAnonymous, @event.IsAnonymous);
                    Assert.Equal(command.PatronType, @event.PatronType);
                    Assert.Equal(command.Id, @event.SourceId);
                    Assert.NotEqual(command.Id, @event.Id);
                    Assert.NotEqual(command.Id, @event.PatronId);
                    Assert.NotEqual(Guid.Empty, @event.PatronId);
                    Assert.NotEqual(Guid.Empty, @event.Id);
                }).Verifiable();
            var repo = new Mock&#x3C;ICommandRepository>();
            repo.Setup(re => re.Save(It.Is&#x3C;CreatePatronCommand>(cpc => cpc.Id == command.Id))).Verifiable();

            ICommandHandler&#x3C;CreatePatronCommand> handler = new PatronCommandHandler(eventBus.Object, repo.Object);
            handler.Handle(command);

            Assert.NotEqual(Guid.Empty, command.Id);
            Mock.Verify(eventBus, repo);
        }

        [Fact]
        public void User_Can_Update_a_Patron()
        {
            UpdatePatronCommand command = new UpdatePatronCommand()
            {
                PatronId = Guid.NewGuid(),
                DisplayName = "Updated Test Patron"
            };

            var eventBus = new Mock&#x3C;IEventBus>();
            eventBus.Setup(bus => bus.Publish(It.IsAny&#x3C;PatronUpdated>()))
                .Callback&#x3C;PatronUpdated>((@event) =>
                {
                    Assert.Equal(command.DisplayName, @event.DisplayName);
                    Assert.Equal(command.IsAnonymous, @event.IsAnonymous);
                    Assert.Equal(command.PatronType, @event.PatronType);
                    Assert.Equal(command.Id, @event.SourceId);
                    Assert.Equal(command.PatronId, @event.PatronId);
                    Assert.NotEqual(command.Id, @event.Id);
                    Assert.NotEqual(Guid.Empty, @event.Id);
                }).Verifiable();
            var repo = new Mock&#x3C;ICommandRepository>();
            repo.Setup(re => re.Save(It.Is&#x3C;UpdatePatronCommand>(cpc => cpc.Id == command.Id))).Verifiable();

            ICommandHandler&#x3C;UpdatePatronCommand> handler = new PatronCommandHandler(eventBus.Object, repo.Object);
            handler.Handle(command);

            Assert.NotEqual(Guid.Empty, command.Id);
            Mock.Verify(eventBus, repo);
        }
    }
}
</code></pre>


Patron Can Be Created and Updated (Again)

<p>Just when I thought I was in a good place to carry forward with retrieving a persisted entity and then modifying its values, I started looking intently into the <a href="https://msdn.microsoft.com/en-us/library/jj554200.aspx">CQRS Journey</a> on MSDN. While reading through their narative, I thought I was really getting to understand how the code was structured. However, once I dug into the source code - well, I was naively mistaken. The notion of having <a href="/posts/2016/user-can-create-new-patron/">a Factory</a> was entirely flawed, as that role of validating and placing Commands on the Event Bus was better suited in the user interface layer (be it a Web Controller, a console library, or some other set of code). I supposed that the Factory could fall under "some other set of code"; however, for the purposes of demonstrating the bare minimum needed to declare an action completed, the Factory was adding one too many steps. I realized that the unit test need not create a Factory to then pass a Command to the Bus. Instead, the Unit Test should <em>assume the command was already on the bus</em>.</p>
<p>If I go back to the notion of "User Can Create New Patron", I have realized that I did it entirely wrong. Since what I wanted to demonstrate was the power and ability of using <code>interface</code> design to better focus on what I want to accomplish, the statement I should have been "User Can Command A Patron To Be Created". This provides a better starting place for me to carry that command forward. The <code>CreatePatronCommand</code> has now already been created (<em>ipso facto</em>, it is in the message queue) and now needs an <code>ICommandHandler</code> to turn it into one or more events and to persist the command for historical referencing.</p>
<h3>The New Command Interfaces</h3>
<p>With this refocus, I now have an <code>ICommand</code> that is handled by an <code>ICommandHandler</code> with access to a <code>ICommandRepository</code> for persistence needs. The narative now becomes:</p>
<p>A <code>Command</code> describes the action that needs to take place. The name of the command (<code>CreatePatronCommand</code>) indicates what should be peformed and the data in the command provides the necessary information to fully execute the command.</p>
<pre><code>using System;

namespace Vigil.Domain.Messaging
{
    public interface ICommand
    {
        /// &#x3C;summary>Gets the command identifier.
        /// &#x3C;/summary>
        Guid Id { get; }
    }
}
</code></pre>
<p>The command, having been put on the bus, is then passed to a <code>CommandHandler</code> which creates one or more events, placing them on the event bus, and persists the command to some storage for archival purposes. Otherwise, the command is of no further use and could be discarded.</p>
<pre><code>namespace Vigil.Domain.Messaging
{
    public interface ICommandHandler
    {
    }

    public interface ICommandHandler&#x3C;TCommand> : ICommandHandler
        where TCommand : ICommand
    {
        void Handle(TCommand command);
    }
}
</code></pre>
<p>In order to persist the command, a <code>CommandRepository</code> is passed to the command handler to presist the command. When needed, this could also fetch data if it is required to do some kind of look-up when creating events.</p>
<pre><code>namespace Vigil.Domain.Messaging
{
    public interface ICommandRepository
    {
        void Save&#x3C;TCommand>(TCommand command) where TCommand : ICommand;
    }
}
</code></pre>


Revisiting Creating and Updating Entities

<p>A simple update of an object is as complex as adding a new instance of the object, which means it is both straight forward and laden with all kinds of caveats and unlying processes. As with <a href="/posts/2016/user-can-create-new-patron/">creating a new Patron</a>, it is trivial for me to put together a contrived example of code that will technically satisfy the requirements for "User Can Update a Patron". A unit Test will create a new Command that will be validated by the Factory and then passed to the MessageQueue for persistance by some other process.</p>
<h2>Command and Tests</h2>
<p>There is no surprising code here. The only differences, at this point, between the <code>CreatePatronCommand</code> and the <code>UpdatePatronCommand</code> is the removal of any fields being required and the addition of an <code>IKeyIdentity</code> identifier.</p>
<pre><code>using System.ComponentModel.DataAnnotations;
using Vigil.Domain;

namespace Vigil.MessageQueue.Commands
{
    public class UpdatePatronCommand : ICommand
    {
        [Required]
        public IKeyIdentity TargetPatron { get; set; }

        [StringLength(250)]
        public string DisplayName { get; set; }
        public bool? IsAnonymous { get; set; }
        [StringLength(250)]
        public string PatronType { get; set; }
    }
}
</code></pre>
<p>The intent is that further down the line, the process that actually performs the update will ignore any fields that are <em>null</em>. I am partial to the idea of only passing data that actually needs changing. In the future, when I need to handle non-nullable data, then I will worry about how to indicate a removal of information. At this point, though, it is tomorrow-David's problem.</p>
<p>The <code>IKeyIdentity</code> is for the issuing code to indicate which entity needs updating. Not all commands will have something like this, as some commands may work on a specific range of entities or all entities.</p>
<p>The unit tests for this command are just as basic as those for the <code>CreatePatronCommand</code> class. They are just for making sure that validation can be performed on the object and that it is simple to create a case where it will fail validation.</p>
<pre><code>using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using Vigil.Domain;
using Xunit;

namespace Vigil.MessageQueue.Commands
{
    public class UpdatePatronCommandTest
    {
        [Fact]
        public void Validation_Requires_TargetPatron()
        {
            UpdatePatronCommand command = new UpdatePatronCommand();

            List&#x3C;ValidationResult> validationResults = new List&#x3C;ValidationResult>();
            Validator.TryValidateObject(command, new ValidationContext(command), validationResults, true);

            Assert.Contains(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.TargetPatron)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.DisplayName)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.PatronType)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.IsAnonymous)));
        }

        [Fact]
        public void Validation_On_DisplayName_Has_Maximum_String_Length()
        {
            UpdatePatronCommand command = new UpdatePatronCommand()
            {
                TargetPatron = KeyIdentity.NewIdentity(),
                DisplayName = "This is a string with lots of letters appended.".PadRight(1000, 'A'),
                PatronType = "This is a string with lots of letters appended.".PadRight(1000, 'A'),
            };

            List&#x3C;ValidationResult> validationResults = new List&#x3C;ValidationResult>();
            Validator.TryValidateObject(command, new ValidationContext(command), validationResults, true);

            Assert.Contains(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.DisplayName)));
            Assert.Contains(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.PatronType)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.TargetPatron)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(UpdatePatronCommand.IsAnonymous)));
        }
    }
}
</code></pre>
<h2>Factory and Added Tests</h2>
<p>The factory does not need much more than it already has. Adding the <code>UpdatePatron</code> method does show that the validation code between the two methods is the exact same, and so I have refactored that into its own protected method. Otherwise, the only real difference is that the <code>key</code> for the <code>QueueCommand</code> method comes from the <code>UpdatePatronCommand</code> instead of being newly generated.</p>
<pre><code>using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using Vigil.Domain;
using Vigil.MessageQueue;
using Vigil.MessageQueue.Commands;

namespace Vigil.Patrons
{
    public class PatronFactory
    {
        protected readonly ICommandQueue _queue;

        public PatronFactory(ICommandQueue queue)
        {
            _queue = queue;
        }

        public FactoryResult CreatePatron(CreatePatronCommand command)
        {
            List&#x3C;ValidationResult> validationResults = ValidateCommand(command);

            if (validationResults.Any())
            {
                return new FactoryResult(validationResults);
            }
            else
            {
                var key = KeyIdentity.NewIdentity();
                _queue.QueueCommand(command, key);
                return new FactoryResult(key);
            }
        }

        public FactoryResult UpdatePatron(UpdatePatronCommand command)
        {
            List&#x3C;ValidationResult> validationResults = ValidateCommand(command);

            if (validationResults.Any())
            {
                return new FactoryResult(validationResults);
            }
            else
            {
                _queue.QueueCommand(command, command.TargetPatron);
                return new FactoryResult(command.TargetPatron);
            }
        }

        protected List&#x3C;ValidationResult> ValidateCommand(ICommand command)
        {
            List&#x3C;ValidationResult> validationResults = new List&#x3C;ValidationResult>();
            Validator.TryValidateObject(command, new ValidationContext(command), validationResults, true);

            return validationResults;
        }
    }
}
</code></pre>
<p>The added tests are just as easy to write as one would expect. One test to make sure that everything can successfully complete when everything is correct, and one test to make sure that if fails meaningfully.</p>
<pre><code>using Moq;
using System;
using Vigil.Domain;
using Vigil.MessageQueue;
using Vigil.MessageQueue.Commands;
using Xunit;

namespace Vigil.Patrons
{
    public class PatronFactoryTest
    {
        // PatronFactory.CreatePatron tests omitted.

        [Fact]
        public void User_Can_Update_a_Patron()
        {
            var queue = new Mock&#x3C;ICommandQueue>(MockBehavior.Strict);
            queue.Setup(q => q.QueueCommand(It.IsAny&#x3C;ICommand>(), It.IsAny&#x3C;IKeyIdentity>())).Verifiable();
            PatronFactory factory = new PatronFactory(queue.Object);
            UpdatePatronCommand command = new UpdatePatronCommand()
            {
                TargetPatron = KeyIdentity.NewIdentity(),
                DisplayName = "Updated Patron Name",
                IsAnonymous = null,
                PatronType = null
            };

            FactoryResult result = factory.UpdatePatron(command);

            queue.VerifyAll();
            Assert.Equal(command.TargetPatron.Id, result.AffectedEntity.Id);
            Assert.Empty(result.ValidationResults);
        }

        [Fact]
        public void User_Cannot_Update_Patron_That_Fails_Validation()
        {
            var queue = new Mock&#x3C;ICommandQueue>(MockBehavior.Strict);
            queue.Setup(q => q.QueueCommand(It.IsAny&#x3C;ICommand>(), It.IsAny&#x3C;IKeyIdentity>())).Verifiable();
            PatronFactory factory = new PatronFactory(queue.Object);

            FactoryResult result = factory.UpdatePatron(new UpdatePatronCommand());

            queue.Verify(q => q.QueueCommand(It.IsAny&#x3C;ICommand>(), It.IsAny&#x3C;IKeyIdentity>()), Times.Never);
            Assert.Null(result.AffectedEntity);
            Assert.NotEmpty(result.ValidationResults);
        }
    }
}
</code></pre>
<p>It feels very anti-climactic to be adding so little code just to "Update" an entity, and it is a little overwhelming to thing of all of the code that needs to be written after this to persist the changes, and all of the code that needs to be written before this to allow a real user to generate the command. However, for this small pocket, the work is complete.</p>


Rovani's Sandbox

Blog Posts - Page 9