<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>


User Can Update a Patron

<p>For the fourth year in a row, on Columbus Day weekend, I have completed the Bank of America Chicago Marathon. Previous years have culminated in mixed results, both by the clock and in my own experience. 2013's marathon was a disaster in both time and how I felt during the race, but provided me with invaluable experience and a drive to do better. By the time the 2014 Chicago Marathon came around, I had taken up speed training with <a href="http://coachleach.com/">Coach Leach</a>, focussed a little more on my running form, and put together a strong showing at the 2014 F3 Half Marathon. However, during last year's race, I had set unrealistic expectations, especially while trying to run with a sore back. 2015 was not a good year for me, overall - but I was determined to turn things around for 2016.</p>
<h2>Looking Back at The First Half of 2016</h2>
<p>A lot of dark things happened in my personal life in 2015; but by early 2016, I had started on a recovery course, and I was determined to make 2016 a year of stabilizing my life and pushing forward on my career, my personal life, and my running. The year started with a trip to Disney for the Dopey Challenge. I <a href="/posts/2016/disney-s-dopey-challenge/">wrote about the experience</a> in January, but it's effect on the rest of the year wasn't fully realized until later in the season. By beginning with a rather relaxed race where I couldn't try to set a personal record, it was a refreshing way to get back into running. I wasn't sore for weeks on end, and I didn't have the mental anguish of another missed opportunity.</p>
<p>After having run 48.6 miles over the course of four days, I then had seventeen short days of rest before I ran the F^3 Lake Half Marathon. I have thoroughly enjoyed this race for the last three years. It provides motivation to continue training through the early winter months. When the weather is beautiful (as it was this year), we all enjoy the fabulous day and run fantastic races. When the weather is awful, we all battle through the elements and then enjoy commiserating about how terribly trying it was. Dropping my personal record <a href="https://www.athlinks.com/athletes/193315718?category=1%2F2%20Mara">by nearly five minutes</a> meant I was in high spirits through the rest of Winter Marathon Training.</p>
<p>Having had a <a href="/posts/2015/3-56-58-2015-wisconsin-marathon/">miserable, terrible, never-to-be-repeated experience</a> at the Wisconsin Marathon in 2015, I had elected to go somewhere completely different for 2016. Since my girlfiend was from New Jersey, it seemed like a really good idea at the time (famous last words) to go ahead and sign up for the 2016 Novo Nordisk New Jersey Marathon. The course was splendid for the size of the race, and the running company was good. This was the first time that I tried running with a pace group, and it is an experience which I shall endevour to replicate in future races. My initial goal was to run with the 3:45:00 pace group (would would have still been a six minute PR), but at the very beginning of the race, I decided to throw caution to the wind (a very strong, raining, cross wind at that) and quickly catch up to the 3:30:00 pace group. If I was reading this on someone else's blog, I would expect a tale of misery at going out to fast, and then crashing around mile 16. Inconceivably, at mile 16, I instead pulled away from the pace group and absolutely shattered my personal record, setting a new best time of <a href="https://www.athlinks.com/Athletes/193315718/Race/256045904">3:24:31</a>.</p>
<h2>#Whole30 Nutrition Program &#x26; A Personal Trainer</h2>
<p>As the summer rolled in, my girlfiend and I decided to do the #Whole30 challenge. In support of her, I did not alter any of my meals or nutrition to cheat the program. Some other endurance athletes, I had read, would mostly do the challenge, but still use their sugar-filled gels during the run. I was determined to be fully compliant throughout the 30 days, including on long runs. The first thing that I noticed was the change in energy output during my weekend runs. Previously, I would experience a high energy for many miles, but I could feel this slowly fade away as the miles grew longer. However, on the #Whole30 plan, I felt I had a high level of energy through many more miles than before - but with a significant and sudden drop after some point. After a bit of trial and error, I was able to add more calories throughout the week, which I found boosted the number of miles I could sustain until exhaustion. I have so much to say about this topic that I should probably just write another post dedicated to this.</p>
<p>Another notable change in habit was working out with a personal trainer two days a week. While this meant reducing the number of days a week I was running, I found that my running economy was greatly improved and my recovery periods were markedly decreased. Between the two changes, I had shed approximately 20 pounds of excess body weight. I also spent a small fortune on new clothes to drape the slimmed down frame.</p>
<p>I could probably go on about this for another three paragraphs, but I'll save that for another post. All of this work over the summer led to a smashing success at the annual Universal Sole Burgers &#x26; Beer 5k race, <a href="http://onlineraceresults.com/race/view_plain_text.php?race_id=54184">completing in 19:21.6</a>; placing 20th overall and 6th in the very competitive M30-34 division. I was estatic with my performance, and it reinvigorated my dedication to training for the Chicago Marathon.</p>
<h2>A New Training Regiment</h2>
<p>With the addition of working out in the gym two days a week, I changed up my running schedule. My week thus looked like this:</p>
<ul>
<li>Monday: Run to work (minimum 9 miles, peaked at 12 miles) between marathon and threshold pace.</li>
<li>Tuesday: Work out with Personal Trainer</li>
<li>Wednesday: Run to work (minimum 9 miles, peaked at 15 miles) between easy and marathon pace.</li>
<li>Thursday: Work out with Personal Trainer</li>
<li>Friday: rest</li>
<li>Saturday: Long run with CARA (between 8 and 22 miles) at easy pace</li>
<li>Sunday: rest</li>
</ul>
<p>I must say that I thoroughly enjoyed this set-up. I never felt the tedium of running that I had felt in previous years. I never felt overly stained or worrying about injury. The whole summer passed without serious incident, and the end of September approached rather quickly.</p>
<h2>End of September</h2>
<p>Then I got married and we went to Paris and London for the honeymoon.</p>
<h2>Chicago Marathon 2016</h2>
<p>The day was finally here, and I felt woefully underprepared. Normally, I would have had everything all packed up the night before, but I was scrambling around and lost when I wanted to be heading to bed. So I just figured I would work it all out in the morning; and so I crashed. I slept horribly. Even when I finally decided to get out of bed, I just couldn't piece together a satisfactory list of what I wanted to bring to race day. It turns out that I had absolutely everything I would normally bring, but I had a nagging feeling the entire L ride downtown that I had forgotten something. On top of that, there was a really annoying passenger that kept wanting to engage me in conversation when I really just wanted to pop in my headphones and listen to some calming piano pieces. Eventually, I arrived at the CARA compound and the familiarity started to fall into place. I started going through the pre-race motions of replacing compression socks and walking shoes with running socks and race shoes; attaching my bib to the shirt I was going to wear; bundling up in an old long-sleeves shirt and worn gloves; and triple checking watch, cellphone, nutrition. There is a lot to be said about routine to clear one's head. I left the compound an hour before race time, and casually walked to my corral. Last year (when the compound was farther), this barely got me into my corral before they closed the gates. This time around, I was easily at the front of Corral C, and found myself in a more relaxed mood because of it. The temperature was cool with only a slight breeze.</p>
<p>Corral C's fastest pace group was a 03:25:00. Having already run faster than that, I had my eye on catching up to the 03:20:00 pace group in Corral B. Once released onto the course, I set myself at a measured pace, and felt good on my quest to catch up with my rabbits. I found them at around mile four but I couldn't get myself to easily pull back to their pace, and I soon found myself creeping ahead of them. I carried on at the pace I was holding, and started doing the math in my head for whether I might catch the 03:15:00 pace group and when I would overrun them. Before the half way point in the race, I had found and passed that pace group. Twice I was able to see my wife, mom, son, and some friends - all estatic to see me. I knew I was going too fast, and when I had a midway split of 01:33:11, I had no doubt that I was going to crash and burn before the end of the marathon. My only goal at this point was to hold out for as long as I could, and see how close I could come to the finish line before it all fell apart.</p>
<p>The 30k mark was about as far as I could get at the pace I was running, and then I had to painfully slow down, which turned into a bit of a run-walk. A few miles later, the 03:15:00 pace group passed me, and then close to the end, the 03:20:00 pace group trotted passed me. I knew they were coming for me, so it didn't completely demoralize me, but there was a sense of loss at knowing what finish time I was losing. Starting with the aid station in mile 20, I was able to get myself to run to the banana tables, eat nearly a full banana, get some water, then proceed with my race. I would walk through the aid station, then start running slowly, then picking up to an acceptable pace. At mile 23.5, I had the first cramp I've ever had during a run; thankfully, I was able to walk it off before the block ended. Michigan Avenue was, once again, a torturously long 2.5 miles. I kept with the Fartlek-like intervals, and the pavement eventually moved along — my eye ever on the clock. I knew I could still set a personal record, as long as I kept moving. Walk a little, slow run a little, easy pace as long as possible; rinse and repeat.</p>
<p>At the 800m mark, I was going to walk another interval, but a friend of mine jump the barricade, ran across Michigan Ave, waved her arms like a crazy person. I looked over to where she came from and found my entourage excitedly cheering for me. It was an unexpected and wonderful surprise, and I couldn't let them see me walk - so on I went! I was able to take that surge of energy, climb over Mount Roosevelt, and run across the finish line.</p>
<h2>Official Results - <a href="http://results.chicagomarathon.com/2016/?content=detail&#x26;idp=999999107FA309000019E6EC">03:21:43</a></h2>
<p>My time for the first half of the marathon was the fastest that I've run 13.1 miles before. It is also the pace that I will need to run to be able to qualify and race in Boston. 03:06:22 would be a very solid time to be able to submit, and would further grant me guaranteed entry into the next years' Chicago Marathon (03:15:00 being the cut off). I feel good having the experience of what that pace will feel like, and how I can best manage the race. Assuming I can move up a corral for next year's Chicago Marathon, I will attempt to attach myself to the 03:05:00 pace group and stick with them the whole race.</p>
<p>The other thing that I learned is that two LaraBars are not nearly enough nutrition to get me through the race. I would have liked at least four, and I could have also used either salt tablets or <a href="http://www.seattletimes.com/seattle-news/health/pickle-juice-yellow-mustard-for-muscle-cramps/">mustard packets</a>. I think the added nutrition would have helped with the energy crash and the cramping may have been from my sodium dropping too low. These are both things that I will try during my next marathon, and if it works out, will definitely be in store for all further races.</p>
<h2>And On a Lighter Note</h2>
<p><a href="https://www.dnainfo.com/chicago/20161009/downtown/chicago-marathon-dogs"><img src="/images/2016chi-cute-puppy.jpg" alt="Adorable Pups Were The Cutest Spectators At The 2016 Chicago Marathon"></a></p>


2016 Chicago Marathon Wrap-up

<p>For a while, I have been battling with where validation should occur, and who is responsible for ensuring that the information in a command is good data. For the first layer of data validation, I am turning to the Command to validate itself — the mere application of data types is a rudimentary form of data validation, so including addition simple validation extends that basic logic.</p>
<h2>Simple Validation</h2>
<p>Taking a queue from the <a href="https://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.ivalidatableobject.aspx"><code>IValidatableObject</code></a> interface, simple validation logic will be handled by the command itself. I am defining <em>simple</em> as validation that requires no external knowledge.</p>
<pre><code>using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using Vigil.Domain;

namespace Vigil.MessageQueue.Commands
{
    public class CreatePatronCommand : ICommand
    {
        [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>This validates that both the <code>DisplayName</code> and the <code>PatronType</code> are not longer than 250 characters and are not empty. There is no validation as to whether the <code>PatronType</code> exists in some look-up table, or whether the <code>DisplayName</code> is unique (or if it even needs to be unique).</p>
<h2>Why A Command Does Not Require Itself Be Valid</h2>
<p>Even though the Command knows <em>how</em> to validate itself, I have decided that the command is not required to actually ensure that it is valid before work is performed on it — for two reasons. First, a Command is merely a carrier for information, and only understands simple rules governing whether the data is in a valid state. There are many cases where it is acceptable for a Command to be in an invalid state — when logging failed attempts, or when saving an in progress state. Second, a Command does not actually know when work is being performed on its information. Other objects (the message queue, the command handler, the command logger) are responsible for deciding if the data needs to be fully valid and then whether the data actually is valid. This was a bit of a struggle for me early on, because if the object knows <em>how</em> to validate itself, shouldn't it also make sure that it is always in a valid state? It was when I started thinking about persisting partial states and persisting failed states that I began to realize how to solve this conundrum.</p>
<h2>Who Validates the Validation?</h2>
<p>In my current system design, I am relying on the Factory to handle validating that a Command's data has passed all of its internal data integrity checks. As I've already mentioned the <code>IValidatableObject</code>, it should come as no surprise that I intend to use the <code>DataAnnotations</code> namespace to perform the validation.</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 = new List&#x3C;ValidationResult>();
            Validator.TryValidateObject(command, new ValidationContext(command), validationResults, true);

            if (validationResults.Any())
            {
                return new FactoryResult(validationResults);
            }
            else
            {
                var key = KeyIdentity.NewIdentity();
                _queue.QueueCommand(command, key);
                return new FactoryResult(key);
            }
        }
    }
}
</code></pre>
<p>There are some odd quirks that I will have to remember, the primary (at this point) being the order that validation occurs, and when it aborts further validation. Jeff Handley goes into more detail in his post <a href="http://jeffhandley.com/archive/2009/10/16/validator.aspx">Validating Objects and Properties with Validator</a>, but the key piece that I took away from it that I hadn't figured out while playing with the API is this:</p>
<blockquote>
<ol>
<li>Validate property-level attributes</li>
<li>If any validators are invalid, abort validation returning the failure(s)</li>
<li>Validate the object-level attributes</li>
<li>If any validators are invalid, abort validation returning the failure(s)</li>
<li>Call its Validate method and return any failure(s)</li>
</ol>
</blockquote>
<h2>Complex Validation</h2>
<p>I have not yet solved the problem of how to validate a command that requires external knowledge. At some point, I am going to need to be sure that a command has valid information with regards to all other information in a system. Account numbers must be unique and sequential; transaction dates must be the same as the date of the batch; schedule effective date ranges cannot overlap. Whatever does the validation will have to have knowledge of the state of other common data points - maybe it doesn't specifically know what the persistence technology is, but the validating object will need to know how to compare the Command's data with persisted data. Who gets this priviledge? I have not yet figured that one out.</p>


Rovani's Sandbox

Blog Posts - Page 9