<p>Command Query Responsibility Segregation (<a href="https://martinfowler.com/bliki/CQRS.html">CQRS</a>) was not something that I easily understood. Martin Fowler did a thorough job of explaining it in often-linked post from 2011. However, I still did not quite grasp it at the time. I also wasn't working on any project large enough or complex enough that it made sense to use a pattern with that level of depth. When I came back to the concept many years later while working on a significantly more complex project, I could put together all of the puzzle pieces but I still couldn't quite see the whole picture. While researching the topic, I stumbled on a blog post by Cesar de la Torre from Microsoft - <a href="https://blogs.msdn.microsoft.com/cesardelatorre/2012/02/22/cqrs-bus-and-windows-azure-technologies/">CQRS BUS and Windows Azure technologies</a>. His picture was well worth the thousands of words that I had already read.</p>
<p><img src="/images/cqrs-diagram.jpg" alt="CQRS - Basic patterns"></p>
<p>I am limiting the scope of this step of the project to just creating a Message Queue in Azure, writing a command to it, and triggering an appropriate <code>Command Handler</code>. As soon as I started working on the problem, though, I was sidetracked with an important and timely concern — how do I safely store connection information to a remote server? Considering that I work on this project on at least three different machines, I need a highly portable and secure way to store the connection information to my instance of Azure without exposing that connection information to anyone who may look at the code on <a href="https://github.com/drovani/Vigil">GitHub</a>. Now, instead of having three steps to this stage, I have four; maybe more.</p>
<h2>Storing Connection Information</h2>
<p><img src="/images/vs2017-inavord-manage-user-secrets.png" alt="User Secrets in Context Menu"></p>
<p>When this migrates to a production ready environment, I will probably use <a href="https://docs.microsoft.com/en-us/azure/key-vault/key-vault-whatis">Azure Key Vault</a> or some similar service to manage these types of important secrets. However, for the limited amount of information that I need to keep, I am just going to use the built-in "User Secrets" that comes with Visual Studio 2017. Using the context menu on a Web Application project provides the option to "Manage User Secrets". This pulls up a <code>secrets.json</code> file that lives (unencrypted) on the local filesystem. There are plenty of caveats to its use, namely that it provides no security outside of making sure these settings exist entirely separate from your code. In order to store the information I needed, my <code>secrets.json</code> file looks similar to this.</p>
<pre><code>{
  "vigil-storage": "vigilstorage",
  "vigil-storage-queue": "commandqueue",
  // sample key - the real one is much longer
  "vigil-storage-key1": "ocJFUuUrYgVppKtO726cC1S..."
}
</code></pre>
<p>In order to access the user secrets to the configuration builder, a small piece is added to <code>Startup.cs</code>.</p>
<pre><code>public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddEnvironmentVariables();

    if (env.IsDevelopment())
    {
        builder.AddUserSecrets("6bf18fc4-44a1-4c9b-98ea-22cc92ed1c94");
    }

    Configuration = builder.Build();
}
</code></pre>
<p>Consuming the secrets is as simple as any other configuration value. Since I only need it right now for the <code>StorageCredentials</code> that get injected into the <code>AzureCommandQueue</code> constructor, I have the creation of the credentials as an extension method on the <code>IServiceCollection</code>. My <code>StartupExtensions</code> class can live anywhere; I have decided to put it in the same project that needs it, <code>Vigil.Azure</code>.</p>
<pre><code>public static class StartupExtensions
{
    public static IServiceCollection AddVigilAzureServices(this IServiceCollection services, IConfigurationRoot configuration)
    {
        services.AddTransient&#x3C;IEventBus, AzureEventBus>()
                .AddTransient&#x3C;ICommandQueue, AzureCommandQueue>()
                .AddTransient(srvProvider =>
                    {
                        var storageCredentials = new StorageCredentials(
                            configuration["vigil-storage"],
                            configuration["vigil-storage-key1"]
                        );
                        CloudStorageAccount storageAccount = new CloudStorageAccount(storageCredentials, true);
                        CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
                        var commandQueue = queueClient.GetQueueReference(configuration["vigil-storage-queue"]);
                        return commandQueue;
                    });

        return services;
    }
}
</code></pre>
<h2>Create a Storage Account in Azure</h2>
<p>This was the easiest step of them all, because there are many wonderful tutorials already created on how to do get started with <a href="https://docs.microsoft.com/en-us/azure/storage/storage-introduction">Azure Storage</a>. It comes down to three simple steps that can all be done in under a minute (once you know your way around).</p>
<ol>
<li>Create a <img src="/images/azure-resource-group-icon.png" alt="icon"> Resource group</li>
<li>Create a <img src="/images/azure-storage-account-icon.png" alt="icon"> Storage Account</li>
<li>View <img src="/images/azure-access-key-icon.png" alt="icon"> Access keys</li>
</ol>
<p>The name of the storage account (<code>vigilstorage</code>) and the value of one of the keys goes into the <code>User Secrets</code>, and <em>voilà</em>, the storage account is created. One item that tripped me up was that I expected to need to create the Queue within the portal. As I eventually figured out, that piece is performed exclusively in code.</p>
<h2>Sending a Message to Azure Queue Storage</h2>
<p>After many hours of digging through tutorials, hunting down <em>dotnet core</em> versions of the libraries, and trial and error - I finally got to a point where my code compiled and executed and I could test it with a <a href="https://www.getpostman.com/">Postman</a> query. I was surprised by how little code it ended up requiring. This is the entirety of what the <code>AzureCommandQueue</code> class looks like:</p>
<pre><code>public class AzureCommandQueue : ICommandQueue
{
    private CloudQueue commandQueue;

    public AzureCommandQueue(CloudQueue commandQueue)
    {
        this.commandQueue = commandQueue;
    }

    public void Publish&#x3C;TCommand>(TCommand command) where TCommand : ICommand
    {
        PublishAsync(command).Wait();
    }

    public async Task PublishAsync&#x3C;TCommand>(TCommand command) where TCommand : ICommand
    {
        await commandQueue.CreateIfNotExistsAsync();

        var newCmd = new Command(command)
        {
            DispatchedOn = DateTime.UtcNow
        };
        var message = new CloudQueueMessage(JsonConvert.SerializeObject(newCmd));
        await commandQueue.AddMessageAsync(message);
    }
}
</code></pre>
<h2>HOLY SHIT I GOT IT TO WORK</h2>
<p><img src="/images/azure-queue-data.png" alt="Data in an Azure Queue"></p>
<p>This was one of those "really cool moments" when it comes together how fantastic my job is and how amazing technology truly is. I just had a tool on my computer simulate a user pushing a non-existant button that sends information to another tool on my computer that is pretending to be a web server which then executed code that I wrote to take that message and securely send it up to the internet and sit on some unknown computer where it will stay and wait for me to call upon it.</p>


Vigil's Azure Command Queue

<p>I may have gone down a long and twisted rabbit hole trying to figure out this problem, but I learned a lot about how model binding along the way, so I consider the whole experiment a productive use of my time, even if I end up ripping it all out in a few weeks. However, since I thought this would be a good idea, I figure others might find a good use for this knowledge. Thus, this is how I am using an explicity constructor when the input is in a <code>JSON</code> format and parameter is bound using the request body.</p>
<pre><code>[HttpPost]
public IActionResult Create([FromBody]CreatePatron command)
</code></pre>
<p>An early lesson when writing Actions is that, in Core MVC, the <code>[FromBody]</code> attribute is required to use the <code>JsonInputFormatter</code>. Setting a new convention for controllers is possible (<a href="http://www.dotnetcurry.com/aspnet-mvc/1149/convert-aspnet-webapi2-aspnet5-mvc6">instructions on how to</a>), but for now I am going to stick with the tedium of remembering to apply it to every parameter.</p>
<p>The purpose of this is that I want the <code>GeneratedBy</code> and the <code>GeneratedOn</code> parameters to be required for every instance of a <code>Command</code>. This ensures that it won't be set by the user (either the end user or another user in a consuming change) since the properties' set methods are <code>protected</code>.</p>
<pre><code>using System;

namespace Vigil.Domain.Messaging
{
    public abstract class Command : KeyIdentity, ICommand
    {
        public string GeneratedBy { get; protected set; }
        public DateTime GeneratedOn { get; protected set; }

        protected Command(string generatedBy, DateTime generatedOnUtc)
        {
            if (string.IsNullOrEmpty(generatedBy)) throw new ArgumentNullException(nameof(generatedBy));
            if (generatedOnUtc == default(DateTime)) throw new ArgumentException($"{nameof(generatedOnUtc)} requires a non-default value.", nameof(generatedOnUtc));
            if (generatedOnUtc.Kind != DateTimeKind.Utc) throw new ArgumentException($"{nameof(generatedOnUtc)} must be DateTimeKind.UTC.", nameof(generatedOnUtc));

            GeneratedBy = generatedBy;
            GeneratedOn = generatedOnUtc;
        }
    }
}
</code></pre>
<p>This poses a problem with using the <code>CreatePatron</code> command as a parameter. The default <a href="https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Formatters.Json/JsonInputFormatter.cs"><code>JsonInputFormatter</code> class</a> uses the <a href="https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Formatters.Json/JsonInputFormatter.cs#L149"><code>JsonSerializer.Deserialize(JsonTextReader, Type)</code> method</a> to create the instance of the model. This method uses the parameterless constructor, which my objects to not have. To solve this problem, I inheritted from the <code>JsonInputFormatter</code> (keeping as much functionality as I could) and proceeded from there.</p>
<h2>CommandInputFormatter Constructor</h2>
<p>All of the fields that are passed to the <code>JsonInputFormatter</code> constructor are stored as private readonly fields. Therefore, I had to create my own private readonly copies of them to use in the methods that I needed to write.</p>
<pre><code>public class CommandInputFormatter : JsonInputFormatter
{
    private readonly IArrayPool&#x3C;char> _charPool;
    private readonly ILogger _logger;
    private readonly ObjectPoolProvider _objectPoolProvider;

    public CommandInputFormatter(ILogger logger
        , JsonSerializerSettings serializerSettings
        , ArrayPool&#x3C;char> charPool
        , ObjectPoolProvider objectPoolProvider)
        : base(logger, serializerSettings, charPool, objectPoolProvider)
    {
        if (charPool == null)
        {
            throw new ArgumentNullException(nameof(charPool));
        }
        _charPool = new JsonArrayPool&#x3C;char>(charPool);

        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
        _objectPoolProvider = objectPoolProvider ?? throw new ArgumentNullException(nameof(objectPoolProvider));
    }
}
</code></pre>
<h2>CommandInputFormatter.CanReadyType</h2>
<p>Since I wanted this formatter to only work for these specific classes, I extended the functionality of the <code>CanReadType</code> method to also filter for just models that implement the <code>Command</code> abstract base class.</p>
<pre><code>protected override bool CanReadType(Type type)
{
    return base.CanReadType(type) &#x26;&#x26; typeof(Command).IsAssignableFrom(type);
}
</code></pre>
<h2>CommandInputFormatter.ReadRequestBodyAsync</h2>
<p>The simplest way for me to change the constructor that <code>JsonInputFormatter</code> uses to generate the model would have been if they had isolated that small piece of the <code>ReadRequestBodyAsync</code> method into its own protected virtual method. However, since they didn't, I have to override the entire thing. Because ASP.NET Core (including MVC) is all open source, I was able to copy the source code from the original and only replace the parts that I needed to.</p>
<pre><code>public override Task&#x3C;InputFormatterResult> ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)
{
    if (context == null)
    {
        throw new ArgumentNullException(nameof(context));
    }
    if (encoding == null)
    {
        throw new ArgumentNullException(nameof(encoding));
    }


    using (var streamReader = context.ReaderFactory(context.HttpContext.Request.Body, encoding))
    {
        using (var jsonReader = new JsonTextReader(streamReader))
        {
            jsonReader.ArrayPool = _charPool;
            jsonReader.CloseInput = false;

            var successful = true;
            EventHandler&#x3C;Newtonsoft.Json.Serialization.ErrorEventArgs> errorHandler = (sender, eventArgs) =>
            {
                successful = false;

                var exception = eventArgs.ErrorContext.Error;

                // Handle path combinations such as "" + "Property", "Parent" + "Property", or "Parent" + "[12]".
                var key = eventArgs.ErrorContext.Path;
                if (!string.IsNullOrEmpty(context.ModelName))
                {
                    if (string.IsNullOrEmpty(eventArgs.ErrorContext.Path))
                    {
                        key = context.ModelName;
                    }
                    else if (eventArgs.ErrorContext.Path[0] == '[')
                    {
                        key = context.ModelName + eventArgs.ErrorContext.Path;
                    }
                    else
                    {
                        key = context.ModelName + "." + eventArgs.ErrorContext.Path;
                    }
                }

                var metadata = GetPathMetadata(context.Metadata, eventArgs.ErrorContext.Path);
                context.ModelState.TryAddModelError(key, eventArgs.ErrorContext.Error, metadata);

                _logger.LogDebug(1, eventArgs.ErrorContext.Error, "Command Input Formatter threw an exception");

                // Error must always be marked as handled
                // Failure to do so can cause the exception to be rethrown at every recursive level and
                // overflow the stack for x64 CLR processes
                eventArgs.ErrorContext.Handled = true;
            };

            object model = GetModel(context);
            var type = context.ModelType;
            var jsonSerializer = CreateJsonSerializer();
            jsonSerializer.Error += errorHandler;
            try
            {
                jsonSerializer.Populate(jsonReader, model);
            }
            finally
            {
                // Clean up the error handler since CreateJsonSerializer() pools instances.
                jsonSerializer.Error -= errorHandler;
                ReleaseJsonSerializer(jsonSerializer);
            }

            if (successful)
            {
                return InputFormatterResult.SuccessAsync(model);
            }

            return InputFormatterResult.FailureAsync();
        }
    }
}
</code></pre>
<p>There are only two lines that differ between the formatters; I was surprised by how little I had to change.</p>
<p>| <code>JsonInputFormatter</code>                                | <code>CommandInputFormatter</code>                   |
|-----------------------------------------------------|-------------------------------------------|
|object model;                                        |object model = GetModel(context);          |
|model = jsonSerializer.Deserialize(jsonReader, type);|jsonSerializer.Populate(jsonReader, model);|</p>
<h2>CommandInputFormatter.GetModel</h2>
<p>Of course, there was a little more that I had to add, but this piece is very specific to my application. This is the block of code that creates the appropriate <code>Command</code> object using the explicit constructor.</p>
<pre><code>private static readonly Dictionary&#x3C;Type, Func&#x3C;string, DateTime, Command>> _commandModelCreators = new Dictionary&#x3C;Type, Func&#x3C;string, DateTime, Command>>();
protected virtual object GetModel(InputFormatterContext context)
{
    if (!_commandModelCreators.ContainsKey(context.ModelType))
    {
        var generatedBy = Expression.Parameter(typeof(string), nameof(Command.GeneratedBy));
        var generatedOn = Expression.Parameter(typeof(DateTime), nameof(Command.GeneratedOn));
        var constructor = context.ModelType.GetConstructor(new Type[] { typeof(string), typeof(DateTime) });
        var newExpr = Expression.New(constructor, generatedBy, generatedOn);
        var lambda = Expression.Lambda&#x3C;Func&#x3C;string, DateTime, Command>>(newExpr, generatedBy, generatedOn);

        _commandModelCreators.Add(context.ModelType, lambda.Compile());
    }
    // @TODO Find a better way to get the current user's name
    return _commandModelCreators[context.ModelType](context?.HttpContext?.User?.Identity?.Name ?? "Anonymous User", DateTime.UtcNow);
}
</code></pre>
<p>I save the compiled expression in the formatter. There might be a better way to cache the results, but I can worry about that optimization later. I would also like to have a better way to pass in the identity of the user generating this command. This works for my testing purposes, but I need a better way to do this in the future. Additionally, it would be better if I could inject the <code>DateTime.UtcNow</code> value to be able to explicitly set it and test again in unit tests.</p>
<h2>Include the CommandInputFormatter</h2>
<p>I was not expecting this piece to turn into a three step process. In order to add an an input formatter with parameters, it needs to be configured through an <code>IConfigureOptions&#x3C;MvcOptions></code>, which is added via a <code>ServiceDescriptor</code> to the <code>Services</code> collection on the <code>IMvcBuilder</code> in the <code>Startup</code> class. I learned all this by searching through the Github repository. Once I found the path through it all, I just duplicated most of it, adapting it to my use case.</p>
<p>The <code>IConfigureOptions&#x3C;MvcOptions></code> is easy to implement. The difficulty was in finding what dependency injections were available for the constructor.</p>
<pre><code>public class VigilMvcOptionsSetup : IConfigureOptions&#x3C;MvcOptions>
{
    private readonly ILoggerFactory _loggerFactory;
    private readonly JsonSerializerSettings _jsonSerializerSettings;
    private readonly ArrayPool&#x3C;char> _charPool;
    private readonly ObjectPoolProvider _objectPoolProvider;

    public VigilMvcOptionsSetup(
        ILoggerFactory loggerFactory,
        IOptions&#x3C;MvcJsonOptions> jsonOptions,
        ArrayPool&#x3C;char> charPool,
        ObjectPoolProvider objectPoolProvider)
    {
        if (jsonOptions == null)
        {
            throw new ArgumentNullException(nameof(jsonOptions));
        }

        _loggerFactory = loggerFactory ?? throw new ArgumentNullException(nameof(loggerFactory));
        _jsonSerializerSettings = jsonOptions.Value.SerializerSettings;
        _charPool = charPool ?? throw new ArgumentNullException(nameof(charPool));
        _objectPoolProvider = objectPoolProvider ?? throw new ArgumentNullException(nameof(objectPoolProvider));
    }

    public void Configure(MvcOptions options)
    {
        options.InputFormatters.Insert(0, new CommandInputFormatter(
            _loggerFactory.CreateLogger&#x3C;CommandInputFormatter>(),
            _jsonSerializerSettings,
            _charPool,
            _objectPoolProvider
        ));
    }
}
</code></pre>
<p>From here, I could have easily just injected the <code>VigilMvcOptionsSetup</code> during startup config. I suspect that there will be more customization that I will want to attach to the <code>IMvcBuilder</code>, so chose to follow the lead from the MVC developers and create an extension method.</p>
<pre><code>public static class MvcBuilderExtensions
{
    public static IMvcBuilder AddCommandFormatter(this IMvcBuilder builder)
    {
        if (builder == null)
        {
            throw new ArgumentNullException(nameof(builder));
        }
        ServiceDescriptor descriptor = ServiceDescriptor.Transient&#x3C;IConfigureOptions&#x3C;MvcOptions>, VigilMvcOptionsSetup>();
        builder.Services.TryAddEnumerable(descriptor);
        return builder;
    }
}
</code></pre>
<p>The final step, to wire it all together, is to add a call to the extension method in the <code>Startup.ConfigureServices(IServiceCollection)</code> method. It is important that my extension method comes after the <code>AddMvc</code> method because I inject the <code>CommandInputFormatter</code> to the beginning of the <code>InputFormatters</code> collection. Reversing the order would put my input formatter behind all of the defaults, and the <code>JsonInputFormatter</code> would grab all of the requests before my input formatter was ever checked.</p>
<pre><code>// Add framework services.
services.AddMvc()
    .AddCommandFormatter();
</code></pre>


Using an Explicit Model Constructor with a JsonInputFormatter

<p>Now that the Vigil Project has breached into the API layer, I started to learn all kinds of new information about what takes place before the Controller's Action method is called and what happens after that method returns. The MVC framework, especially while using Visual Studio, make it incredibly easy to forget about all of the heavy lifting that the framework does – long before my code is ever executed. It is only when I wanted to start changing how pieces worked that I really start to see the true depth and breadth of what Microsoft has created. As I begin to discover new pieces of the framework, I felt that the best way to retain this information is to repeat it; and since no one around me wants to hear about all of this, I'll just type it into a blog post.</p>
<h2>Upon First Introduction</h2>
<p>My first introduction to MVC (through various tutorials) gave me the impression that the full stack looks basically like this:</p>
<p><img src="/images/mvcpipeline-initial.svg" alt="Initial Pipeline Assumptions"></p>
<p>There's a lot of black box magic going on in that diagram. But you know what? It doesn't matter. When all I wanted to do was respond to a simple request, then all I had to do was create a <code>Controller</code> and an <code>Action</code> and then <em>magic happened</em>, and I got a functioning application. Do I have any clue about how the data got to the method? Or how the <code>Controller</code> was even instantiated in order for <em>something</em> to have an object to call my method? <strong>Nope</strong>! And that's the point.</p>
<h2>The First Challenge - Explicit Constructor</h2>
<p>The Create action for the <code>BaseController</code> is simple. It just take an instance of the <code>CreatePatron</code> command and publishes is to the <code>CommandQueue</code>. This is essentially the same as the unit test that proved that a "<a href="/posts/2016/patron-can-be-created-and-updated-again/">patron can be created</a>".</p>
<pre><code>[HttpPost]
public IActionResult Create([FromBody]CreatePatron command)
{
    if (command == null || !ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }
    else
    {
        CommandQueue.Publish(command);
        return Accepted(Url.Action(nameof(Get),
            new { id = command.PatronId }));
    }
}
</code></pre>
<p>However, this quickly goes awry the first time I execute the code, because the <code>CreatePatron</code> command (as with all <code>PatronCommand</code> classes) has no default constructor. MVC <em>really</em> wants a default constructor, but I <em>really</em> want to guarantee that the <code>GeneratedBy</code> and <code>GeneratedOn</code> values are properly populated. "Surely," though I, "this should be an easy update and I'll be able to move onto something else."</p>
<p>I was wrong.</p>
<h2>What Creates an Instance of My Model</h2>
<p>Early in the tutorials I was following, they allude to this magical <em>Binding Handler</em> which takes data from the request and binds it to the model and passes it to the action. I now had an idea of <em>what</em> I was looking for, with the assumption that the Binding Handler is what would create the instance of my model. I also assumed that whatever was doing this work was a result of some default setting.</p>
<p>This was the first time I started really digging into what happens during the <code>Startup</code> portion of the application. <code>Startup</code> is the default class that is created with any new MVC project, and it is wired into the <code>WebHostBuilder</code> during the execution of the <code>Main</code> event. I didn't dig into all of the different methods that automatically get generated, because I had a this specific action that I was trying to find.</p>
<pre><code>// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc()
}
</code></pre>
<p>As a bit of a tangent, this is where I am estatic that .NET Core is open source. For previous frameworks, I would have to scour the web for someone to have already done all of this digging, and decided it was worth it to create a post, and then I would have to manage to find their post, and then hope it was close enough for me to get the answers I needed. Now that everything is open source, I can just go <a href="https://github.com/aspnet/mvc">view the code itself</a> to find out what happens.</p>
<pre><code>    public static class MvcServiceCollectionExtensions
    {
        public static IMvcBuilder AddMvc(this IServiceCollection services)
        {
            if (services == null)
            {
                throw new ArgumentNullException(nameof(services));
            }

            var builder = services.AddMvcCore();

            builder.AddApiExplorer();
            builder.AddAuthorization();

            AddDefaultFrameworkParts(builder.PartManager);

            // Order added affects options setup order

            // Default framework order
            builder.AddFormatterMappings();
            builder.AddViews();
            builder.AddRazorViewEngine();
            builder.AddRazorPages();
            builder.AddCacheTagHelper();

            // +1 order
            builder.AddDataAnnotations(); // +1 order

            // +10 order
            builder.AddJsonFormatters(); // &#x3C;--- THIS LOOKS PROMISING!!!

            builder.AddCors();

            return new MvcBuilder(builder.Services, builder.PartManager);
        }
</code></pre>
<p>What does the <code>AddJsonFormatters()</code> extension method do? I can go <a href="https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Formatters.Json/DependencyInjection/MvcJsonMvcCoreBuilderExtensions.cs">look that up</a>. That method calls an internal method that adds Service Descriptor to the service collection to resolve an <code>IConfigureOptions&#x3C;MvcOptions></code> into a <code>MvcJsonMvcOptionsSetup</code>. That <a href="https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Formatters.Json/Internal/MvcJsonMvcOptionsSetup.cs">source code</a> for that class indicates that it adds a <code>JsonInputFormatter</code> to the list of Input Formatters in the <code>MvcOptions</code> object that gets passed to it. Continuing to dive further into the <a href="https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Formatters.Json/JsonInputFormatter.cs">source code</a>, I finally found the magic line of code!</p>
<pre><code>namespace Microsoft.AspNetCore.Mvc.Formatters
{
    public class JsonInputFormatter : TextInputFormatter
    {
        /* snip the constructor */

        public override Task&#x3C;InputFormatterResult> ReadRequestBodyAsync(
            InputFormatterContext context,
            Encoding encoding)
        {
                    /* snip a bunch of set-up code */
                    try
                    {
                        // HERE IT IS!!!
                        model = jsonSerializer.Deserialize(jsonReader, type);
                    }
                    /* snip clean-up code */
                }
            }
        }
        /* snip the rest of the class */
    }
}
</code></pre>
<h2>What Do I Know, Now?</h2>
<p><img src="/images/mvcpipeline-chooseinputformatter.svg" alt="Getting the Input Formatter"></p>
<p>During startup, using the <code>AddMvc</code> extension method, by default, will add a <code>JsonInputFormatter</code> to the list of Input Formatters. When reading the request body, the <code>ReadRequestBodyAsync</code> using the JSON serializer's <a href="http://www.newtonsoft.com/json/help/html/M_Newtonsoft_Json_JsonSerializer_Deserialize_1.htm"><code>Deserialize</code> method</a>. I don't see anyway to injet something to override just that one line - or even the object creation portion.</p>
<p>Zoomed in - this is the tiny piece that I learned of the whole pipeline. I have no idea if this is to scale or not, but it certainly feels like only a small step.</p>
<p><img src="/images/mvcpipeline-chooseinputformatter.zoom.svg" alt="Getting the Input Formatter"></p>
<h2>What Do I Need To Do?</h2>
<ol>
<li>Inherit from <code>JsonInputFormatter</code> and override the <code>ReadRequestBodyAsync</code> method.</li>
<li>Create a new setup class to inject the new input formatter, implementing <code>IConfigureOptions&#x3C;MvcOptions></code>.</li>
<li>Create a new static class and an extension method on <code>IMvcBuilder</code> to add dependency injection for the setup class.</li>
<li>Crib unit tests from the Mvc code base.</li>
<li>Hope that it all really works.</li>
</ol>


Discovering MVC - The ASP.NET Core MVC Stack

<p>As I was writing the <a href="/posts/2017/introducing-vigil-web-api/">previous post</a>, it came as a shock how far behind my posts on the progress of the Vigil Donor Relationship Management System had gotten. I was going too deep into the code and making too many changes that I didn't pause to write a post about my progress. My posts are 22 commits behind, and there are quite a few changes I've made to the workflow and to the application. As a way to catch up on all the missed posts that I should have written, I am putting this one together as a status report of the project/journey/solution.</p>
<p>In terms of workflow, I have embraced the <a href="https://guides.github.com/introduction/flow/">GitHub Flow workflow</a> (both for Vigil and for this blog). For my little project, since there is no discussion and no deployments (as of yet), the workflow is as simple as Branch, Commit(s), Pull, Merge, Delete. I like the way that a merge can squash all of the commits made on a branch, so that I have one summarized collection of everything that I did. This way, I can easily differentiate the content of a post by doing one per Pull Request / Merge. Hopefully, this process will now keep the posts coming regularly, help me be more concise about what should be in a post, and better contain runaway developing.</p>
<h2>Quantity of code</h2>
<p>As I look at the total row count of all of the code, I am actually surprised by how many lines of code I have produced. It is a pittance compared to what I could output if I had been working on this project full time for the last two years. However, for something that I have only been poking at every once in a while, I still find myself astonished that all of the simple "Create this" and "Update that" have turned into this much actionable code.</p>
<h2>Vigil.Domain</h2>
<p>The Domain project contains a lot of interfaces and a few abstract classes. The key functionality that has been created here are the structure for what it takes to build a messaging and event sourcing system. More will probably be added here as a way to keep shared functionality across different implementations - be in for <code>Patron</code> entities or an Ordering and Inventory system or possibly a job taks/queue system.</p>
<p>The reading that I have done with regards to Domain Driven Design (DDD) talk about establishing a <em>Domain Language</em>. My interpretation is to enforce that in a shared project that creates the core concept of how the <em>domain</em> should be structured and implemented. The rest of the application is just extending these interfaces and base classes and providing for meaning over the abstractions. There was a lot of flux in the earliest stages of the <code>Vigil.Domain</code> project, but it has already settled into a stable state. My assumption is that over time, this will be the project that undergoes the least amount of change, but that changes to it will have broad reaching effects.</p>
<h3>Vigil.Domain.Tests</h3>
<p>The consensus for <a href="http://stackoverflow.com/questions/243274/how-to-unit-test-abstract-classes-extend-with-stubs">testing abstract classes</a> seems to be to either never use abstract classes or to create extremely simple inherited classes and run the tests on those. I have chosen the later option (obviously) and so far the tests seem comprehensive. Though, as with most of this project, I have constant feelings of imposter syndrome where someone smart is going to come along and tell me how awful this whole thing is and how I'm doing it all wrong.</p>
<h2>Vigil.Patrons</h2>
<p>As is the only concrete implementation of the <em>Domain Language</em>, this project is a semi-functional proof-of-concept. I keep trying to focus myself on considering it as production code, thus holding myself to the same requirements to unit test everything and keep functionality as a <a href="https://www.youtube.com/watch?v=R2Aa4PivG0g">complex web of small pieces</a>. Commands available handle the simplest of actions - <code>CreatePatron</code>, <code>UpdatePatronHeader</code>, <code>DeletePatron</code>. The <code>PatronCommandHandler</code> knows what to do with the commands, which is to just create the applicable event and push it to the Event Bus. The <code>PatronEventHandler</code> methods only update the <code>Patron</code> entity that was persisted using an <code>IPatronContext</code>.</p>
<p>Upon close examination, the Patron project is barely less of an abstraction than the Domain project from which it derives most of its functionality. It is  disheartening to know that even the after writing roughly 300 lines of code, there is very little that I can do with the code. However, I can also celebrate in knowing that it takes only 300 lines of code to be able to implement the core functionality fo what it takes to Create, Read, Update, and Delete a <code>Patron</code>. The only thing left (after I unit tested everything) was to wire the Patron project to a real implementation of all of the interfaces it was depending on.</p>
<h2>Vigil.Sql</h2>
<p>I talked about this project in detail in <em><a href="/posts/2017/illusions-of-queues-and-buses/">Illusions of Queues and Buses</a></em>. The short of it is that I wanted to put together an extremely simple implementation of the <code>ICommandQueue</code> and <code>IEventBus</code> so that I could use it in the <code>Vigil.WebApi</code> project.</p>
<h2>Vigil.WebApi</h2>
<p>The <a href="/posts/2017/introducing-vigil-web-api/">post previous to this</a> explains why I decided to venture into the API layer of the application, instead of continuing to implement more of the Patron project or begin working on another subsystem of the application. It certain has been gratifying to see everything come together and be properly integrated and <em>just work</em>.</p>
<h2>Future Tangents</h2>
<p>There are a number of quality-of-life improvements that could easily cause me to stray down a long tangent of work. It would be nice if my project templates included all of the settings that I apply to each new project. These include:</p>
<ul>
<li>Set the "Author" to "drovani"</li>
<li>Set "RepositoryType" to "git"</li>
<li>Set "RepositoryUrl" to "https://github.com/drovani/Vigil"</li>
<li>Clear the "Description"</li>
<li>Set "SignAssembly" to "true"</li>
<li>Set the "AssemblyOriginatorKeyFile" to the <code>vigil.snk</code> in the root solution folder</li>
<li>For Test projects:
<ul>
<li>Set the "RootNamespace" to be the same as the project being tested.</li>
<li>Add <code>xunit.runner.json</code> and set the "methodDisplay" to "method"</li>
<li>Include the <code>Moq</code>, <code>xunit</code>, and <code>xunit.runner.visualstudio</code> NuGet packages</li>
</ul>
</li>
</ul>
<p>Other side projects would include putting together all of the shiny automated build routines that all of the big projects have. Being able to have Pull Requests kick off builds to make sure nothing breaks - that would be cool. Turning all of the projects into NuGet packages and making them a little more portable would be an interesting experiment.</p>
<p>My problem is that each of these tangents only delay my progress on creating productive code that leads the project to a useful state.</p>


22 Month Status Report

<p>Thus far in the series, the Vigil Journey project has been able to <a href="/posts/2016/user-can-create-new-patron/">create a patron</a>, <a href="/posts/2016/user-can-update-a-patron/">update a patron</a>, and have those redefined as "<a href="/posts/2016/patron-can-be-created-and-updated-again/">a patron can be created and updated</a>". However, as acknowledged in those posts, this was all smoke and mirrors. Nothing was being persisted, and once the unit tests were run, there was no lasting effect of the code. All of the tests passed and there were lots of pretty green check marks, but no residual digital substance. Additionally, there was no application that could be left running with which someone could interact.</p>
<p>I began getting antsy about needing to have some semblence of real progress. Something that I could launch and point to and say "see there; it works!" This was my primary motivator for quickly (and sloppily) writing the <a href="/posts/2017/illusions-of-queues-and-buses/"><code>SqlCommandQueue</code> and <code>SqlEventBus</code></a> classes. I wanted to be able to demonstrate <em>something</em>.</p>
<h2>Recent Observations</h2>
<p>While my initial instinct was to spin up a complete user interface for this; what better way to show progress than to open a web browser and display grid views and form fields, thought I. However, I also had grand schemes of building a full API for the UI to utilize. This kept my ambitions in check, and after researching for ways to directly interact with an API, allowing me to reach a more attainable goal. Thus, the next  layer of the project - which is to instantiate the <code>CreatePatron</code> command and pass it to an <code>ICommandQueue</code>. Utilizing my <code>SqlCommandQueue</code>, I could wire that to a database, which would handle persistence of <code>Command</code> objects, passing those to a <code>CommandHandler</code>. These would, in turn, generate events and put them on the <code>SqlEventBus</code>; which would call the appropriate <code>EventHandler</code> classes, and thus persist the changes to the relational database.</p>
<p>An unexpected (though, in hindsight, entirely predictable) revalation I had while adding this additional layer to the application is that each piece seems to have a higher cost to initialize the first proof of concept. When all I was looking for was the ability to <em>create a patron</em>, I could claim that "it works" when the unit test proved that a short piece of code did what it was supposed to do. The <code>PatronCommandHandler</code> class required no external libraries &#x26;emdash; in fact, going up the dependencie chain, <code>System</code> is the only required library because of <code>DateTime</code> and <code>Guid</code>. However, implementing even a cheap Command Queue or Event Bus requires the <code>EntityFrameworkCore</code> and <code>System.Linq</code> NuGet packages. Adding the ability to stand up even a small Rest API requires <code>Microsoft.AspNetCore</code>, <code>Microsoft.AspNetCore.Mvc</code>, <code>Microsoft.AspNetCore.Routing</code>, and if I want to use a webserver to host the code, then it requires bringing one or more of the <code>Microsoft.AspNetCore.Server</code> packages. There is a lot more experimentation, debugging, and unit testing required for each step. This is something that I'm going to have to keep in mind anytime I get the grand ambitions to tack on another layer to the application.</p>
<h2>ASP.NET Core MVC as an API</h2>
<p>Previous versions of ASP.NET MVC separated out the <code>Controller</code> base class from the WebAPI controller base class. With ASP.NET Core MVC, there is no difference between an API controller and a web controller. I see this as being a real advantage when it comes to migrating code that was all crammed together in a web application, when an easier way to manage it would be as two different applications. Since a core goal of this entire <em>Vigil Journey</em> is to separate responsibilities wherever possible, I like having the responsibility of user presentation being entirely separate from the responsibility of the command and query part of the workflow.</p>
<p>The <code>PatronController</code> is going to start as a simple controller that implements the four basic tenents of data: Create, Read, Update, Delete - or CRUD. Each action has a different Verb, Model, and return values.</p>
<p>|        | Http Verb | Model              | Success        | Failure              |
|--------|-----------|--------------------|----------------|----------------------|
| Create | Post      | CreatePatron       | Accepted (202) | BadRequest (400)     |
| Read   | Get       | PatronId           | Ok (200)       | NotFound (404)       |
| Update | Put       | UpdatePatronHeader | Accepted       | BadRequest, NotFound |
| Delete | Delete    | PatronId           | Accepted       | NotFound             |</p>
<pre><code>using Microsoft.AspNetCore.Mvc;
using System;
using System.Linq;
using Vigil.Domain.Messaging;
using Vigil.Patrons.Commands;

namespace Vigil.WebApi.Controllers
{
    [Route("api/[controller]")]
    public class PatronController : Controller
    {
        private readonly ICommandQueue commandQueue;
        private readonly Func&#x3C;VigilWebContext> contextFactory;

        public PatronController(ICommandQueue commandQueue,
            Func&#x3C;VigilWebContext> contextFactory)
        {
            this.commandQueue = commandQueue;
            this.contextFactory = contextFactory;
        }

        [HttpGet]
        public IActionResult Get()
        {
            using (var context = contextFactory())
            {
                var patrons = context.Patrons.Where(p => p.DeletedOn == null);
                return Ok(patrons);
            }
        }

        [HttpGet("{id}")]
        public IActionResult Get(Guid id)
        {
            using (var context = contextFactory())
            {
                var patron = context.Patrons.Find(id);
                if (patron == null)
                {
                    return NotFound();
                }
                else
                {
                    return Ok(patron);
                }
            }
        }

        [HttpPost]
        public IActionResult Create([FromBody]CreatePatron command)
        {
            if (command == null || !ModelState.IsValid)
            {
                return BadRequest(ModelState);
            }
            else
            {
                commandQueue.Publish(command);
                return Accepted(
                    Url.Action(nameof(Get), new { id = command.PatronId })
                );
            }
        }

        [HttpPut("{id}")]
        public IActionResult UpdateHeader(Guid id,
            [Bind(nameof(UpdatePatronHeader.DisplayName),
                  nameof(UpdatePatronHeader.IsAnonymous),
                  nameof(UpdatePatronHeader.PatronType))] UpdatePatronHeader command)
        {
            if (command == null || !ModelState.IsValid)
            {
                return BadRequest(command);
            }
            using (var context = contextFactory())
            {
                if (context.Patrons.Find(id) == null)
                {
                    command.PatronId = id;
                    commandQueue.Publish(command);
                    return Accepted(Url.Action(nameof(Get), new {
                        id = command.PatronId
                    }));
                }
                else
                {
                    return NotFound(id);
                }
            }
        }

        [HttpDelete("{id}")]
        public IActionResult Delete(Guid id)
        {
            using (var context = contextFactory())
            {
                if (context.Patrons.Any(p => p.Id == id))
                {
                    commandQueue.Publish(
                        new DeletePatron(User.Identity.Name, DateTime.Now)
                        {
                            PatronId = id
                        }
                    );
                    return Accepted();
                }
                else
                {
                    return NotFound(id);
                }
            }
        }
    }
}
</code></pre>
<h2>Unit Tests before Functional testing</h2>
<p>Before I attempted to launch Kestrel or IIS Integration, I needed to write a Unit Test. I got a little ahead of myself on this one. I wrote this first unit test, and then went off on a coding tangent, which caused a massive refactoring to occur. The unit tests never got completed for this version of the <code>PatronController</code>, but it does provide a quick overview as to how I handled the constructor requirements of the controller and checks for the return value.</p>
<pre><code>using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using Moq;
using System;
using Vigil.Domain.Messaging;
using Xunit;

namespace Vigil.WebApi.Controllers
{
    public class PatronControllerTest
    {
        public readonly ICommandQueue cmdQueue = Mock.Of&#x3C;ICommandQueue>();
        public readonly Func&#x3C;VigilWebContext> Context;

        public PatronControllerTest()
        {
            var serviceProvider = new ServiceCollection()
                .AddEntityFrameworkInMemoryDatabase()
                .BuildServiceProvider();
            var builder = new DbContextOptionsBuilder&#x3C;VigilWebContext>()
                .UseInMemoryDatabase(databaseName: "TestHelper")
                .UseInternalServiceProvider(serviceProvider);

            Context = () => new VigilWebContext(builder.Options);
        }

        [Fact]
        public void Get_Returns_EmptyCollection_WhenThereAreNoPatrons()
        {
            var controller = new PatronController(cmdQueue, Context);

            var result = controller.Get() as OkObjectResult;

            Assert.NotNull(result);
            Assert.NotNull(result.Value);
        }
    }
}
</code></pre>
<p>If nothing else, this post reinforced that I need to write posts more often, and do a better job of isolating concepts into branches and merging small amounts of code at a time.</p>


Introducing Vigil Web API

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


Rovani's Sandbox

Blog Posts - Page 8