<p>Creating a patron (by which I mean, issuing a command such that some process somewhere will instantiate an actual Patron entity, and perhaps persist it in some useful manor) is all well and good, until someone tries to stuff in data that isn't valid. Users like to do things like this all the time, so I am going to attempt to protect against it from the beginning. Additionally, by setting up the mechanisms to test validation and perform validation, I should be able to keep a culture of enforcing these conventions throughout development.</p>
<h2>*"Cannot"</h2>
<p>With everything revolving around commands, telling a user something can't be done is less accurate, and it is more about declining to queue the command and letting the user know why. This starts by actually validating the command in question.</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>
<h2>**"Validation"</h2>
<p>Who actually performs the validation is questionable. For now, I have decided to place the onus on the command to know what makes it valid. As a first step, I am just using the <code>DataAnnotations</code> attributes, as they serve my needs for now. In the future, I know that I will need to do look-up validation (is the <code>PatronType</code> valid), but for now I am just demonstrating that the bare minimum works.</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>
<h2>Testing the Code</h2>
<pre><code>CreatePatronCommandTest:
  ✅ Validation_On_DisplayName_Has_Maximum_String_Length
  ✅ Validation_Requires_DisplayName_and_PatronType

PatronFactoryText
  ✅ User_Can_Create_New_Patron
  ✅ User_Cannot_Create_Patron_That_Fails_Validation
</code></pre>
<p>Of course, since new code has been added, new tests need to be made. Following the Microsoft convention for where tests are located, the solution is broken into two root folders: src and test. There is a one-to-one matching of projects with real code in the src folder, and projects that hold the unit tests for those projects. Test projects have the same name as their target, suffixed with '.Tests' (eg. <code>src\Vigil.Domain</code> and <code>test\Vigil.Domain.Tests</code>). The folder structure in the two projects should be identical, and all test classes have the same name as their target class, suffixed with 'Test' (eg. <code>Vigil.Patrons.PatronFactory</code>, <code>Vigil.Patrons.PatronFactoryTest</code>).</p>
<pre><code>using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using Xunit;

namespace Vigil.MessageQueue.Commands
{
    public class CreatePatronCommandTest
    {
        public void CreatePatronCommand_Defaults_IsAnonymous()
        {
            CreatePatronCommand command = new CreatePatronCommand();

            Assert.False(command.IsAnonymous, "Default Value of CreatePatronCommand.IsAnonymous changed from 'false'.");
            Assert.Null(command.DisplayName);
            Assert.Null(command.PatronType);
        }

        [Fact]
        public void Validation_Requires_DisplayName_and_PatronType()
        {
            CreatePatronCommand command = new CreatePatronCommand();

            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(CreatePatronCommand.DisplayName)));
            Assert.Contains(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(CreatePatronCommand.PatronType)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(CreatePatronCommand.IsAnonymous)));
        }

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

            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(CreatePatronCommand.DisplayName)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(CreatePatronCommand.PatronType)));
            Assert.DoesNotContain(validationResults, vr => vr.MemberNames.Any(mn => mn == nameof(CreatePatronCommand.IsAnonymous)));
        }
    }
}
</code></pre>
<pre><code>using Moq;
using System;
using Vigil.Domain;
using Vigil.MessageQueue;
using Vigil.MessageQueue.Commands;
using Xunit;

namespace Vigil.Patrons
{
    public class PatronFactoryTest
    {
        [Fact]
        public void User_Can_Create_New_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);

            FactoryResult result = factory.CreatePatron(new CreatePatronCommand()
            {
                DisplayName = "Test User",
                IsAnonymous = false,
                PatronType = "Test Account"
            });

            queue.VerifyAll();
            Assert.NotEqual(Guid.Empty, result.AffectedEntity.Id);
            Assert.Empty(result.ValidationResults);
        }

        [Fact]
        public void User_Cannot_Create_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.CreatePatron(new CreatePatronCommand());

            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>


User Cannot* Create Patron That Fails Validation**

<p>For simplicity, the <code>PatronFactory</code>'s <code>CreatePatron</code> method just returned an <code>IKeyIdentity</code>. This was a simple interface that requires an <code>Id</code> of type <code>Guid</code>. When the creation method was always assumed to work correctly, this was fine - I don't have to worry about validation checking, data errors, or anything that might cause a failure. However, in the real world, I need to be aware of these things. As such, the first refactor that I'm going to perform is to change the return type to a multi-purpose class.</p>
<h3>FactoryResult</h3>
<pre><code>using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

namespace Vigil.Domain
{
    public class FactoryResult
    {
        public ICollection&#x3C;ValidationResult> ValidationResults { get; protected set; }
        public IKeyIdentity AffectedEntity { get; protected set; }

        public FactoryResult(ICollection&#x3C;ValidationResult> validationResults)
        {
            ValidationResults = validationResults;
        }
        public FactoryResult(IKeyIdentity affectedEntity)
        {
            AffectedEntity = affectedEntity;
        }
    }
}
</code></pre>
<p>The <code>PatronFactory</code> will now return this class. If there were problems, then the <code>ValidationResults</code> collection will contain elements; if all went well, then <code>IKeyIdentity</code> should not be null. Tests were updated to reflect this, and now I am ready to add validation (<a href="/posts/2016/user-cannot-create-patron-that-fails-validation/">next post</a>).</p>
<h3>A Quick Note About Contracts</h3>
<p>Currently, Code Contracts is not supported for .NetCore and is not coming to C# 7.0, which makes me very sad - it is also the number one requested feature for <a href="https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2320188-add-non-nullable-reference-types-in-c">C# on the Visual Studio uservoice</a>. While the primary use of Design by Contract was for eliminating null references, there were still plenty of other places it was extremely useful. Especially with <code>Guid</code>s becoming the primary source of identifiers, it was very helpful to be able to Require that a Guid could not be Empty, or that a value was in a given range.</p>
<p>So, it is with a sad heart that I have removed Contracts from this project entirely. I will start putting in null reference checks where appropriate, but for the most part, I will do what I can to find an alternative solution.</p>


A Word On Factory Results and Contracts

<p>The first thing that I learned with Dependency Injection is that it encourages a mindset of "I'll figure that out that later." This allows me to put in the bare minimum for what might pass a test, even though I know it will have all kinds of complex integration somewhere down the line. To start this little experiment, I am going to put together a tiny amount of arguably functional code. I will start with the very simple definition of what a User is, what it means to Create an entity, and how a Patron is represented.</p>
<h2>*"User"</h2>
<p>A "User" in this case is the arbitrary creator of a command and consumer of the factory. For now, the User is the test suite (powered by xUnit).</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
    {
        [Fact]
        public void User_Can_Create_New_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);

            IKeyIdentity result = factory.CreatePatron(new CreatePatronCommand()
            {
                DisplayName = "Test User",
                IsAnonymous = false,
                PatronType = "Test Account"
            });

            queue.VerifyAll();
            Assert.NotEqual(Guid.Empty, result.Id);
        }
    }
}
</code></pre>
<h2>**"Create"</h2>
<p>At this point, I am going to define Create as issuing the command to <em>something else</em> to instantiate and persist a new representation of the entity.</p>
<pre><code>using System.Diagnostics.Contracts;
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 IKeyIdentity CreatePatron(CreatePatronCommand command)
        {
            Contract.Requires(command != null);
            Contract.Ensures(Contract.Result&#x3C;IKeyIdentity>() != null);

            var key = KeyIdentity.NewIdentity();

            _queue.QueueCommand(command, key);

            return key;
        }
    }
}
</code></pre>
<h2>***"Patron"</h2>
<p>A patron, this early in development, is an abstract representation of what should be created - it does not care about persistence or structure.</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>
<h2>ICommandQueue Interface</h2>
<p>The most basic, simple interface with the bare minimum for what a message queue would need to implement.</p>
<pre><code>using Vigil.Domain;

namespace Vigil.MessageQueue
{
    public interface ICommandQueue
    {
        void QueueCommand(ICommand command, IKeyIdentity key);
    }
}
</code></pre>
<h2>ICommand Interface</h2>
<p>This is just a simple way to identify commands and provide a way for future restrictions and contracts, when I need them.</p>
<pre><code>namespace Vigil.Domain
{
    public interface ICommand
    {
    }
}
</code></pre>


User* Can Create** New Patron***

<p>There can be a lot of issues with figuring out how to identify an object, especially as I try to track it across various services, platforms, persistance strategies, and even entire systems. For a while, I played around with just having every object contain its own identification field. However, it was painful having to remember to put the same and correct field(s) on every entity. I stumbled upon a blog post (which I cannot find anymore), which talked about pulling the key out into its own class, and have everything inherit from there. I'm not entirely sure I like the idea of a super-base-class, but I think it at least gives me a good place to isolate the key into a globally consistent way.</p>
<h2>Globally Unique Identifier</h2>
<p>Having the identifier at the time of initialization turned out to save all kinds of problems for me. When persisting to a database, I no longer have to wait to select the inserted record to find its identity. I can pass entities between services, pass the key to another service, or check on queues by that Guid.</p>
<h2>IKeyIdentity Interface</h2>
<p>By abstracting the key to an interface, I can decide later if and how I would like to change it. This will limit the places that are impacted if I need to change out the type of the Id, or add more fields. Also, by having methods use an interface instead of a concrete class, it becomes much easier to mock this when testing. Faking an interface is much easier than building entire test classes.</p>
<pre><code>using System;

namespace Vigil.Domain
{
    public interface IKeyIdentity
    {
        Guid Id { get; }
    }
}
</code></pre>
<h2>KeyIdentity Interface</h2>
<p>This is the basic implementation of the <code>IKeyIdentity</code> interface. It follows the <code>ValueObject</code> convention, making the <code>Guid</code> immutable, but also adds the ability to compare any two objects by their <code>Guid</code>.</p>
<pre><code>using System;
using System.ComponentModel.DataAnnotations;
using System.Diagnostics.Contracts;

namespace Vigil.Domain
{
    public class KeyIdentity : IEquatable&#x3C;KeyIdentity>, IKeyIdentity
    {
        public static KeyIdentity NewIdentity()
        {
            return new KeyIdentity();
        }

        [Key]
        public Guid Id { get; protected set; }

        protected KeyIdentity()
        {
            Id = Guid.NewGuid();
        }

        protected KeyIdentity(Guid id)
        {
            Id = id;
        }

        public override bool Equals(object obj)
        {
            if (ReferenceEquals(null, obj))
            {
                return false;
            }
            if (ReferenceEquals(this, obj))
            {
                return true;
            }
            if (obj.GetType() != GetType())
            {
                return false;
            }
            return Equals((KeyIdentity)obj);
        }

        public bool Equals(KeyIdentity other)
        {
            if (other == null)
            {
                return false;
            }
            return Equals(other.Id, Id);
        }

        public static bool operator ==(KeyIdentity left, KeyIdentity right)
        {
            return Equals(left, right);
        }
        public static bool operator !=(KeyIdentity left, KeyIdentity right)
        {
            return !Equals(left, right);
        }

        public override int GetHashCode()
        {
            return Id.GetHashCode();
        }

        public override string ToString()
        {
            return Id.ToString();
        }

        [ContractInvariantMethod]
        private void ObjectInvariant()
        {
            Contract.Invariant(Id != Guid.Empty);
        }
    }
}
</code></pre>


Everything Gets an Id

<p>As I have been working on the Vigil project, I have been accidentally stumbling onto various patterns. I will go in search of a way to solve some particular problem, and end up losing several hours while I research some reference the author made about a concept (or, usually, an acronym) at the end of a post as some kind of <em>a posteriori</em>. The two largest design patterns that I am most excited about are Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES).</p>
<h2>Accidentally Implementing CQRS</h2>
<p>I found that I wasn't enjoying how all of my database logic was being tied up first inside of my Controller. I refactored, pulling all of the database logic out and putting it into its own class (someone had used the word <em>Repository</em> somewhere, so I called it that). I have always liked pulling code out of the Web Application project and putting it into its own project - so this new Repository got moved there. However, it meant that the View Models that I was using in the Controller could no longer be access by the Repository. Thus, the View Models got moved to the (what is now called) Domain project. But wait - now I have to modify a class in the Domain project if I want to change some data passed to the View. This didn't look right, so the View Models went back into the Web Project and a new set of classes were made - I called these Models. Ok, but now I need a way to turn the View Models into Models - or more accurately, extract the data from one and reconstruct it in the other. For this, I invented Mappers, which just handled shuttling data between my (what I found out were called) POCO classes. It turns out that Mappers can roughly be translated into Command Handlers, if I think of the Factory as a bus, and the POCO as my Command.</p>
<p>Thus, my commands and queries are separated out. Queries are happening in the Repositories, and Commands are happening in the Factories. Event Sourcing is also half way to being implemented, because my commands get pushed up to and object that then handles what to do with them. This means all I am really missing is separating the validation of a command from the actual execution of the command, and I still need to add Event Sourcing.</p>
<h2>Where Am I Going With This?</h2>
<p>There are lots of examples of implementing little pieces of CQRS and ES here and there, spread throughout the web. What I could not find was a single series of posts about taking a completely greenfield project and building up each component of the code, including unit testing. From there, it would be a set of posts about integration and doing integration testing. I think that is where I want to take the Vigil Project. I will keep a branch with "snapshots" of where the code is at each blog post, and I can provide a post detailing each piece of the project. This will include my thoughts for each direction I took, places where I changed my mind (either voluntarily or by force), and the actual code that was generated.</p>
<p>We'll see how this goes. Any ideas on a rough template for what this series might look like? Let me know below.</p>


Stumbling Into Design Patterns

<p>I am working on migrating my blog from the old hosted Wordpress site that I was using to be hosted by GitHub pages, powered by Jekyll.</p>
<p>Why, you might ask. Because I can.</p>
<p>Also, because I want to use my domain to host this, and I <em>think</em> that I can do that with Google Domains and this site. We'll see how that works out.</p>
<h2>Progress</h2>
<ul>
<li>2016-08-11: I migrated from the beginning through 02 April 2014. It's a good start, I think.</li>
<li>2016-08-12: I've migrated through 23 Jan 2015. Slowly but surely!</li>
<li>2016-08-17: Since I had to fix the encoding on all of the markdown files, I spent most of the day fixing all of the question marks.</li>
<li>2016-08-24: I migrated everything from the Wordpress blog, and some of the more important posts from Exactly One Hobby.</li>
</ul>


Hello World!

<p>The <em>Dopy Challenge</em> is a four day event at Walt Disney World Resorts.</p>
<ol>
<li>Thursday - Pluto's 5k</li>
<li>Friday - Minnie's 10k</li>
<li>Saturday - Donald Duck's Half Marathon</li>
<li>Sunday - Mickey Mouse's Marathon</li>
</ol>
<p>In completing the Half Marathon and full Marathon, <em>Dopey Challenge</em> participants also satisfy the requirements for the <em>Goofy's Race and a Half Challenge</em>. This results in six medals, six t-shirts, and four extremely early mornings. I had a lot of fun doing the events, but once is certainly enough for me. It was a unique tour of the parks, getting to run through two for the half marathon and all four for the full marathon; however, circling Epcot two additional times for the 5k and 10k made the final return trip at the end of the marathon torturous. Getting up at 3:45 for four mornings in a row put a huge damper on enjoying the rest of the trip. Combine that with the overall cost, and I cannot see myself doing the challenge again; however, I would consider doing the <em>Goofy Challenge</em>, again.</p>
<h2>My Experience and Lessons Learned</h2>
<p>If you are reading this post, you probably already know enough about the challenge that I don't need to spell out all the details. The <a href="http://www.rundisney.com/disneyworld-marathon/#dopey-challenge">runDisney website</a> does a sufficient job describing the event beyond what I wrote above. I ran the Half Marathon with my girlfriend, but did the other three races by myself. There are a couple of key lessons that I definitely learned (the hard way) that would have greatly improved my experience.</p>
<h3>Submit your Proof of Time Qualifying Results</h3>
<p>This is something that I missed when I registered. For the Chicago Marathon, the organizers send out multiple emails reminding runners to log into the website and add their Proof of Time. Since I didn't do this, I was stuck at the back for all four races. It was <em>awful</em>. As someone who can casually run a 24 minute 5k, I was stuck behind all of the walkers — all of which seemed perfectly happy walking six wide through the narrow parts of the course. The 10k was just as bad. The half marathon was as bad, but I noticed it less, since I was running with at my girlfriend's pace, and she was perfectly content slowing to a walk during the bottlenecks. For the marathon, it was absurd how often I was running through and around large groups with zero course etiquette.</p>
<p>If you are in a later corral for any of the races, expect to be standing around for a very long time. It was at least 41 minutes between the race start and when I was on course for the 5k, 49 minutes for the 10k. For the half and full marathon races, it was over an hour. If you are staying at Disney, take the latest possible bus you can, and take your sweet ass time getting to the corral. It is close to negligent how long it takes to get everyone onto the course. Additionally, expect significant delays throughout the race. The course narrows to just a single lane on a narrow access road throughout many different parts of the course. I understand the need, from an operations standpoint, for this (their employees still need to get to work); but the bottleneck brings athletes to a complete standstill.</p>
<h3>This Isn't a Race, It's a Guided Tour Of Disney</h3>
<p>It wasn't until I was halfway through the Half Marathon that I had the realization that these aren't races, like every other running event I had done. Instead, this was a paid, self-guided tour through the various parks at Disney World. There are no awards for overall place or age bracket places; few people are attempting to qualify for Boston. The entertainment along the course is, in fact, designed to delay you - who can pass up a picture with your favorite Disney characters? The challenge is also a great way to pad the number of participants for the 5k and 10k, and to convince runners to stay at the parks a few extra days. Especially with the expo being on Wednesday, you have to be there for at least four five nights - because who is going to go home Sunday night.</p>
<h3>You Will Get Sick Of Seeing That Damn Golfball</h3>
<p>Since all four races start and end in the Epcot parking lot, you will have to run through the front, and around back of <em>Spaceship Earth</em> four different times. Come the end of the marathon, you are going to loathe seeing that geodesic horror once more. After I finished the marathon, I had the choice of which park we were going to visit, and while I would have liked to walk around Epcot, I hated the idea of seeing it yet again that I chose to go to <em>Animal Kingdom</em> instead (had a wonderful time there, too).</p>
<h3>Extend Your Trip An Extra Day</h3>
<p>A friend who works for Disney said that the second weekend in January used to be the slowest weekend at the parks, which is why that weekend is now Marathon Weekend. It is now also one of their business non-holiday weekends. However, I can attest from experience that nearly everyone goes home on the Monday after the marathon. The park and the resort we lodged at were both nearly empty. Park lines were almost nonexistent and there were no crowds at restaurants during peak meal times. If you can afford to stay an extra day, definitely plan on spending Monday doing all of the things that you would normally have to wait in long lines.</p>
<h3>Enjoy The weekend</h3>
<p>In spite of all of these early mornings, terribly long corrals, mediocre race support, and exhaustive expense — it certainly was a fun weekend, made all the better by the company and the visits to the parks. I am glad to have done it, but more at being able to say that I've done it. In the future, there are certainly bigger challenges that await the ambitious feats of endurance I might undertake (Ragnar, RAGBRAI, Ironman, etc).</p>


Rovani's Sandbox

Blog Posts - Page 10

User Cannot* Create Patron That Fails Validation**

A Word On Factory Results and Contracts

User* Can Create New Patron*

Everything Gets an Id

Stumbling Into Design Patterns

Hello World!

Disney's Dopey Challenge