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 a posteriori. The two largest design patterns that I am most excited about are Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES).
Posts in "Rovani in C♯"
I’ve finally done it; I finally ripped, twisted, and otherwise cajoled the default MVC template, Identity code, and a few other tweaks I wanted to make into something I am semi-confident will be a good starting point for future projects. Which is really to say ? I’m at a stopping point and I’ll probably burn it all to the ground, tomorrow.
In the quest to get to a Minimum Viable Product, I wanted to be able to wrap together a set of projects that would act as a complete framework for future projects. Every (nearly every) project requires users and a way for them to register and login. I had already tied myself to the IdentityDbContext for user and role management. Initially, I had my base context (VigilContext) inherit from IdentityDbContext. I had trouble coming to grips with having every project then required to bring in the Microsoft.AspNet.Identity.EntityFramework assembly. As I was explaining a completely unrelated problem to a coworker, it dawned on me that the whole point of Bounded Contexts was to have multiple contexts, and limit them to only a narrow scope. VigilContext was not going to be used everywhere; its purpose is for database initialization and future migrations.
I have found that it is better to put structure in place around a project before going hog wild on implementation. While I recognize that some practices grow organically, a healthy amount of structure up-front can save a project from technical bankruptcy down the line. The two tools that I use early and often are interfaces and contract classes.
Two key library decisions needed to be made this week: choosing the object-relational Mapping (ORM) framework, and choosing a membership provider. To cut right to the end, Entity Framework and ASP.NET Identity were the solutions that I have chosen to utilize throughout the software. This week’s commit has been getting the initial implementation created, customized, and tested.
There are many posts out there for how to configure a database schema to handle scheduling events. The part that I found difficult to find was an algorithm for calculating future dates for each type of recurring schedule. I have started this series on Recurring Gifts as a way to document the process I went through to build the current system. Some features include:
I am not sure why I started using Knockout, but I have had an overall positive experience with the framework. I was very intrigued with their hands-on tutorials built into the site, which made getting started fairly easy. I walked through them step-by-step, writing out all of the code examples by hand, and diligently debugging typos when the example would not execute as expected. From there, I took the simple step of starting a small side-project just to see how it would all interact. At that point, it became quickly obvious that the tutorials suck and are missing large pieces of information that are vital to get just a basic application going. I also found that there are two tutorials that are completely worthless in terms of getting start - they are advanced topics that I still have not found an applicable usage.
The ASP.NET Identity system is designed to replace the previous ASP.NET Membership and Simple Membership systems. It includes profile support, OAuth integration, works with OWIN, and is included with the ASP.NET templates shipped with Visual Studio 2013.
Now that I have been tinkering with Knockout for about a year, I have finally settled on a host of design patterns that I feel strike a nice balance between rigid consistency and flexible prototyping. I like to have all of my code look very similar. I can look at most code that I have written and know about when I worked on it last. I can usually even look at code that several other developers have touched and see what is mine and what is everyone else’s code. Now that I have a team to direct and an expanding code base to maintain, I have realized that I need to document my own code patterns.
I work almost exclusively on the Microsoft WISC stack. The first response that I hear from almost every single developer that I’ve chatted with is something along the lines of “oh, that’s all closed source software”. It makes me want to throttle them. Mostly because it is an entirely antiquated line of thinking that just shows a lack of actual knowledge of the ecosystem.