2016 was a busy year - in total, I ran eight races. While four of them were all in one weekend for Disney’s Dopey Challenge, it was still a lot of early mornings for me. For 2017, I am going to scale things back a bit - which really just means removing the one racing weekend.
I have come to the point where I am building out the initial proof-of-concept for the WebAPI portion of this project. This gives me a place to continue testing out features, and see if how I envisioned things would work can actually work. One of the first parts of unit testing the controller was to mock any of the properties that I need to use that the web server would ordinarily wire up. In a
Controller that primarily entails the
ControllerContext, which would also wire the
Controller.HttpContext properties. So how do I do that?
Now that I have revised my approach for what constitutes creating and updating entities, I am going back to my
Patron entity to rework the create and update commands. I have already scrapped the
Factory class and its associated unit tests, and go forward with code creation.
Just when I thought I was in a good place to carry forward with retrieving a persisted entity and then modifying its values, I started looking intently into the CQRS Journey on MSDN. While reading through their narative, I thought I was really getting to understand how the code was structured. However, once I dug into the source code - well, I was naively mistaken. The notion of having a Factory was entirely flawed, as that role of validating and placing Commands on the Event Bus was better suited in the user interface layer (be it a Web Controller, a console library, or some other set of code). I supposed that the Factory could call under “some other set of code”; however, for the purposes of demonstrating the bare minimum needed to declare an action completed, the Factory was adding one too many steps. I realized that the unit test need not create a Factory to then pass a Command to the Bus. Instead, the Unit Test should assume the command was already on the bus.
A simple update of an object is as complex as adding a new instance of the object, which means it is both straight forward and laden with all kinds of caveats and unlying processes. As with creating a new Patron, it is trivial for me to put together a contrived example of code that will technically satisfy the requirements for “User Can Update a Patron”. A unit Test will create a new Command that will be validated by the Factory and then passed to the MessageQueue for persistance by some other process.
For the fourth year in a row, on Columbus Day weekend, I have completed the Bank of America Chicago Marathon. Previous years have culminated in mixed results, both by the clock and in my own experience. 2013’s marathon was a disaster in both time and how I felt during the race, but provided me with invaluable experience and a drive to do better. By the time the 2014 Chicago Marathon came around, I had taken up speed training with Coach Leach, focussed a little more on my running form, and put together a strong showing at the 2014 F3 Half Marathon. However, during last year’s race, I had set unrealistic expectations, especially while trying to run with a sore back. 2015 was not a good year for me, overall - but I was determined to turn things around for 2016.
For a while, I have been battling with where validation should occur, and who is responsible for ensuring that the information in a command is good data. For the first layer of data validation, I am turning to the Command to validate itself — the mere application of data types is a rudimentary form of data validation, so including addition simple validation extends that basic logic.