<p>All of my other marathon posts seem to have the "three parts" theme going, so it probably fits for this writing. On the second of May,
I ran the Wisconsin Marathon in Kenosha. It is combined with a half-marathon, and a delayed start 5k. I had a terrible experience, but I came away with some fantastic personal post-race analysis.</p>
<h2>1) Terrible Marathon Course</h2>
<p>Pre-race logistics were fantastic. There were plenty of port-a-pots that I was in line for less than two minutes, with only fifteen minutes before the race started. Most other races I have been to include extremely long lines that snake out even a half hour before race start. The gear check was easily accessible and close to the start line. The self-seeded corrals were large enough that there was no crowding at any of the pace signs (at least from what I could see between the 7:00/mile and the 10:00/mile corrals). The race started on time, and most people seemed to do pretty well in that first mile at keeping with their selected pace.</p>
<p>The first twelve miles shared the same course as the half-marathon. There were a few gently rolling, small hills, and the pavement was almost always in good condition. Water stops were a little far apart and a little understaffed, but it was a small race and I can accept that. Had the weather been any warmer at this point (and runners thus taking more time at the tables), it would have been a real hindrance to anyone trying to run while grabbing water. The very northern point of the course had a long bend to the right, just before the turn-around, which seemed to stretch on forever - but that's just a mental part of the course, not something I would deduct from the quality score of the course.</p>
<p>However, once the half-marathon turned around to head to their finish, the course took a complete nose-dive. Cheering was already lacking in the northern half, but it became almost non-existent in the southern half. However, I figure that is part of being a small field. One of the worst parts of the course where patches on gravel. Not that nicely packed, small grain gravel - no, this was freshly dumped, large, pointy rocks with sharp edges that jam into your foot through the thin racing shoes. I felt really bad for anyone running in minimal or five-finger shoes. That would have been just disastrous. The worst part was between miles 18 and 20. It was two long miles, at the very southern point in the race, that were completely without shade and on freshly laid, sticky, heat-radiating, jet black pavement $endash; with one water station. Absolute, race killing, misery. My pace was slipping going into that stretch, but that took everything out of me. I had nothing left by the time I pulled out of that awful zone.</p>
<h2>2) Poor On Course Support</h2>
<p>As I mentioned before, the water stations (with Gatorade) were small. They were also spaced a bit farther apart than I was comfortable with. Allegedly, they also ran out of Gatorade at the last two stations shortly after I had passed them (a friend who finished fifteen minutes behind me said they were out of Gatorade). I don't know if this was because of lack of volunteers or not buying enough for the size of the field, but that seems to be a huge oversight. Additionally, there was nothing but water and Gatorade on course, and one table of PowerGel around mile 19. I would have killed for a banana at each hydration station after mile 20, and I'm sure those following me were in even worse shape.</p>
<h2>3) Sad Post-Race Party</h2>
<p>The website advertises "Our race offers everything you can dream of, plus our famous Big Cheese Medal and a brat and beer at our Post Race Party!" Directly after the finish line was water in bottles (good), bananas (great), plain bagels (acceptable), and chocolate milk (the best). However, that was it (well, there might have been Gatorade, but I didn't go looking for it). The Big Cheese Medal isn't all that big - but there's a picture of cheese on it. My pet peeve is that it is the same medal for the full and the half marathon - only the ribbon is different. The brat was less than special, and cut in half and stuffed into a pita - a PITA! Who puts a brat in a pita? It goes in a bun! The only condiment options were yellow mustard and ketchup. This is Wisconsin - brats are a culinary staple. How did they screw it up this badly? And the beer was probably a 6 oz serving. Very weak.</p>
<p>Overall, I would not recommend that marathon. If you happen to be in Kenosha, first ask yourself why you're in Kenosha; then, see if you can run the half-marathon. I would have probably had a very positive race experience if all I ran was the half-marathon; it's a shame the race was so terrible on the back half of the course.</p>
<p>Random footnote: if I had run the 5k, I would have placed first overall for men, possibly first overall. The top three times were:</p>
<ol>
<li>19:25 - Leslie Patterson, 32F</li>
<li>19:54 - Samantha Helgesen, 26F</li>
<li>21:32 - Jeffery Kiekhofer, 31M</li>
</ol>


3:56:58 - 2015 Wisconsin Marathon

<p>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.</p>
<ul>
<li>Create NotImplementedAttribute</li>
<li>Extend Identity membership classes</li>
<li>Create Interface for data context</li>
<li>Create Data Context</li>
<li>Create minimal tests</li>
<li>Minor Clean ups</li>
</ul>
<h2>NotImplementedAttribute</h2>
<p>Sort of like a TODO in the code, I pepper classes that still need work, or are just a placeholder shell with this attribute. This makes it so I can easily add a Code Analysis rule to mark it as incomplete, or I can add an ObsoleteAttribute to the NotImplementedAttribute. The compiler will issue a warning and I can easily track down any places I left marked as Not Implemented.</p>
<h2>Vigil Identity Classes</h2>
<p>By default, the Identity classes use a string as the primary key. Internally, it is a serialized Guid, but I could not find a good reason why this was masked. Also, I wanted to play with inheriting the classes ? so I did exactly that. For now, the "System" classes are just the Identity classes, with a Guid key, and table names explicitly set to match the class name (thus overriding the <a href="http://stackoverflow.com/questions/29904898/classes-inherited-from-identity-objects-not-included-in-code-first-migrations">IdentityDbContext's default</a> of naming them "AspNet_____").</p>
<h2>Data Context</h2>
<p>Now is when the fun gets to start ? time to start making some actual progress towards real data.</p>
<ol>
<li>Create the IVigilContext interface, to expose the bare minimums.</li>
<li>Create the Database Context: VigilContext</li>
<li>Inherit it from the IdentityDbContext generic class (so I can use those beautiful Vigil____ classes I created).</li>
<li>Inherit it from the IVigilContext interface and implement the "AffectedBy" and "Now" properties.</li>
<li>Create three tests:</li>
<li>Initialize and Create the database ? this runs Entity Framework model validation. I wish I could find a way to do this without actually having to create the database, but I was unable to find a way to expose the EF method that runs the validation.</li>
<li>Verify that the explicit constructor is setting the AffectedBy and Now properties. It is a menial test, but it makes sure no one breaks it in the future.</li>
<li>Assert that the Set method works for at least one model. This serves two purposes ? it makes sure that the Context is calling its base class's Set method, and it makes it so that code gets covered by a test, thus passing Code Coverage analysis.</li>
</ol>
<h2>Minor Clean Up Duty</h2>
<p>I misspelled the name of the core project, spelling it "Vigi.Data.Core". This meant renaming the project, updating the Assembly name, default Namespace, the folder name (which also caused a rename on all files in the project), the namespace in existing classes, and references to the project. Thankfully, I caught it before I was creating objects that referencing those elsewhere.</p>
<p>In order to get complete Code Coverage for unit tests, I created a test just to call the constructor for the NotImplemented Attribute (it throws a NotImplemented Exception). However, the last line in that test is an Assert.Fail, which should never be reached. This causes the Code Coverage to say that line was never executed, and thus not covered. Obviously, I do not care about Code Coverage in the Testing project, so I added a codeCoverage.runsettings file, which explicitly excludes the Vigil.Testing.Data assembly from analysis.</p>
<blockquote>
<p>Added Vigil Users and Roles implementation of the Identity framework, and added two quick tests for VigilContext.</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/9bca8542c5a0f099032631c133215a5bd9c28aae">Commit 9bca8542c5a0f099032631c133215a5bd9c28aae</a></p>
</blockquote>
<blockquote>
<p>Added Entity Framework and Identity Framework.
Customized the Identity objects with Vigil objects, including using a Guid as the primary key, and adding a RoleType enum. Added a .runsettings file to exclude the Vigil.Testing.Data project from Code Coverage reports. Corrected the "Vigi.Data.Core" misspelling to "Vigil.Data.Core".</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/8be35473aa84138f6ee362d083dd424726345089">Commit 8be35473aa84138f6ee362d083dd424726345089</a></p>
</blockquote>
<blockquote>
<p>Added tests to validate that the Vigil* tables have the correct names, since there was a problem with them being overwritten by the IdentityDbContext.</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/4b68465701f111a806a920e7ec4d12de697aeee7">Commit 4b68465701f111a806a920e7ec4d12de697aeee7</a></p>
</blockquote>


Laying the Foundation

<p>After several false starts, the convention for how to organize a solution seems to have come together. This also includes how to change the default project settings, and how to keep everything tidy as the software grows.</p>
<h3>Vigil.Data Solution</h3>
<p>This solution will contain all projects in the Vigil.Data namespace. This includes the central collection of Entity Framework data models, projects for DDD Bounded Contexts, and each project needed for services. There will be future solutions for the web projects, automated routine projects, importing pipelines, export processes, etc.</p>
<ul>
<li>Vigil.Data.Code: where the Entity Framework Code First data models exist, including necessary abstract classes, interfaces, and extension methods.</li>
<li>Vigil.Data.Modeling: contains all of the Entity Framework specific code that pertains to modelling the data into the data store (database), including the DbContext, Database Migrations, DbInitializers, and interfaces. This does not include any bounded contexts that may exist in the future.</li>
<li>Vigil.Data.Services: services (which handle the business rules and workflows), specific-use data models, data mappers, validation, and supporting interfaces will all reside in this project.</li>
<li>Vigil.Testing.Data: all unit tests will be rooted in the namespace Vigil.Testing, with the sub-namespaces reflecting the project(s) they are testing. Thus, this will have all of the tests for the Data projects.</li>
</ul>
<p>Once these projects are created, there are three property pages that I immediately change from the defaults.</p>
<h3>Assembly Information</h3>
<ul>
<li>Check the Company and Copyright information to make sure they reflect the project that I am creating (and not the computer's defaults).</li>
<li>Set the Assembly Version to 0.1.* (default the Build and Revision Numbers)</li>
<li>Set the File version to 0.1.0.0</li>
</ul>
<p>Later, as the project grows and meaningful features are added, I will manually increase the minor version number as appropriate. Maybe even increase the Major Version, too!</p>
<h3>Signing</h3>
<blockquote>
<p>Benefits of strong naming your assembly first:</p>
<ul>
<li>Strong naming your assembly allows you to include your assembly into the Global Assembly Cache (GAC). Thus it allows you to share it among multiple applications.</li>
<li>Strong naming guarantees a unique name for that assembly. Thus no one else can use the same assembly name.</li>
<li>Strong name protect the version lineage of an assembly. A strong name can ensure that no one is able to produce a subsequent version of your assembly. Application users are ensured that a version of the assembly they are loading come from the same publisher that created the version the application was built with.</li>
<li>Strong named assemblies are signed with a digital signature. This protects the assembly from modification. Any tampering causes the verification process that occurs at assembly load time to fail. An exception is generated and the assembly is not loaded.</li>
</ul>
<p>—Why use strong named assemblies? answer by Kyle Rozendo</p>
</blockquote>
<h3>Code Contracts</h3>
<ul>
<li>Set the Assembly Mode to "Standard Contract Requires"</li>
<li>Enable Runtime Checking at "Full"</li>
<li>Set the <a href="http://stackoverflow.com/a/17892803/28310">Contract Reference Assembly</a> to "Build"</li>
</ul>
<blockquote>
<p>Initial projects for the Core data models, data modeling objects, data services, and data testing.</p>
<p>Added public assembly signing, code contracts, application versioning, and copyright notifications.</p>
<p>—<a href="https://github.com/drovani/Vigil/commit/527fabb81ff6383f8ece46848feb2e329c131201">Commit 527fabb81ff6383f8ece46848feb2e329c131201</a></p>
</blockquote>


Vigil.Data Solution and Initial Projects

<p>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:</p>
<ul>
<li>Ability to scheduled gifts by daily intervals, weekly intervals, monthly (by date) intervals, and monthly intervals by relative point. From there, it is simple math to do Quarterly, Yearly, or any other multiple.</li>
<li>Ability to place gift generation On Hold until a certain date.</li>
<li>Ability to Cancel gift generation on or after a certain date.</li>
<li>Ability to makes changes that apply on a certain date.</li>
<li>Easy to answer the question of "why was this gift created" because all gifts are linked to the schedule that generated it.</li>
</ul>
<p>A few limitations that may constraint its universe utility:</p>
<ul>
<li>Only one active schedule can be created. Can only do "first Friday of every Month", not "first Friday of every Month, and third Tuesday of every other Month."</li>
<li>Cannot schedule by the phase of the moon (not even joking ? this was an actual request) ? though it could be fudged by using a Daily schedule.</li>
<li>Cannot schedule based on National Holidays (also an actual request).</li>
<li>Schedules can only pause and restart once (via the Header.HoldUntilDate).</li>
</ul>
<h2>Database Schema</h2>
<p>Instead of inventing a database schema from nothing, I did what I do best — stand on the shoulders of giants, and Microsoft's SQL Server team is a pretty huge giant. Turning to their documentation on the <a href="https://msdn.microsoft.com/en-us/library/ms178644.aspx">SQL Server Agent job schedules</a>, I opened up the msdb.dbo.sysschedules table. I adjusted some of the definitions to fit my need and built my schema from there.</p>
<h2>Schedules Data Schema</h2>
<p>There were three major changes that I made to the SQL schedule.</p>
<ol>
<li>Frequency Interval, for weekly recurrences, is a bit flag in the SQL Agent schema. Since there is already an enum in the mscorlib, I changed the schema to use the System.DayOfWeek enum values.</li>
<li>Frequency Interval, for monthly relative recurrences, uses 1-7 for Sunday-Saturday, 8 = Day, 9 = Weekday, 10 = Weekend day. I only need the days of the week, so it made sense to also adjust this to use the System.DayOfWeek enum values.</li>
<li>I dropped all notion of "sub day" scheduling. There is no need to have gifts created at multiple points in a day.</li>
</ol>
<p>A common approach to handling querying the event dates is to store a list of all future dates. I can also use this to determine when
the gift was actually created, and use this as an audit for gift creation. By tying the Audit to the Schedule, it is very easy to find
out exactly why an Audit was created.</p>
<p><img src="/images/recurring-schema.png" alt="Recurring Schema"></p>
<h2>Evolution Path</h2>
<p>There were two mistakes I made in the original implementation of this schema. First, I had the End conditions on the Schedule. The thought was that this would be mildly helpful with knowing why the generation of gifts might have started and stopped. Potentially, a termination point would be reached, gifts would stop being generated, then a new schedule would be added, thus resuming creation. However, the actual hit rate for this situation was zero. All it did was ridiculously complicate the algorithm for parsing the schedules.</p>
<p>Additionally, I previously had the Start Date on the Schedule. This also was confusing, as two schedules could be created and cause a gap in the timeline. It is much more easier to implement one "pause until" setting than try and handle skips. My use case was exactly zero for needing multiple start and stops, which is why I have pulled back on the complexity a bit for this second round.</p>
<h2>Up Next</h2>
<p>The next post is going to start to demonstrate how I implemented various parts of the C♯ algorithm to generate the dates in a schedule. These collections then are combined to provide for a final list of all dates.</p>


Recurring Gifts — Part 1: Database Schema

<blockquote>
<p>There are only two hard things in Computer Science: cache invalidation and naming things.</p>
<p>-Phil Karlton</p>
</blockquote>
<p>To any seasoned developer, this is entirely too true, and <a href="http://www.quora.com/Why-is-naming-things-hard-in-computer-science-and-how-can-it-can-be-made-easier">many</a>
<a href="http://blog.stackoverflow.com/2009/03/it-stack-overflow-update-naming-is-hard/">people</a> have <a href="http://seesparkbox.com/foundry/naming_css_stuff_is_really_hard">written</a>
extensively on why this is so hard. For this particular exercise, I have to decide what to the call the core object that represents a (potentially) giving unit in Vigil. Trolling through existing applications, here some options I have come across, and why I rejected them:</p>
<ul>
<li>Client - feels too impersonal for a DRM, though I know there are non-profits that use this as their preferred term.</li>
<li>Constituent - the term is mostly used with voting system. Also, I am really loathe to type out "Constituent" thousands of times.</li>
<li>Customer - this term is associated more with a point-of-sale system than a donation tracking system.</li>
<li>Donor - not all names in the database are going to be actual donors. Some will just be people that purchased something, many will not even have given (in a system I recent worked on, around 55% of the names were non-donors).</li>
<li>Entity - this conflicts heavily with Entity Framework, where the Entity object is used everywhere.</li>
<li>Patron - this is a compelling term, since it has the dual definition of being both a person who gives financially, and a customer to a store.</li>
</ul>
<p>The other part of the name is that it needs to pair with all of the auxilary tables that will be prefixed with:</p>
<ul>
<li>______Address</li>
<li>______Attachment</li>
<li>______BankAccount</li>
<li>______Code</li>
<li>______ContactBase</li>
<li>______CreditCard</li>
<li>______Date</li>
<li>______Email</li>
<li>______Identifier</li>
<li>______Note</li>
<li>______Number</li>
<li>______Payment</li>
<li>______Person</li>
<li>______Phone</li>
<li>______Relationship</li>
</ul>
<p>And that's just the preliminary list!</p>
<p>I had initially gone with Entity, since that it is what our current system uses. However, I quickly tired of running into the namespace conflicts with EF, and thus went searching for alternatives. I had almost settled on Constituent, until I went to start the re-factoring and after the twelfth time of typing it, realized it was going to cause <a href="http://www.ninds.nih.gov/disorders/carpal_tunnel/detail_carpal_tunnel.htm">CTS</a>. Patron was a late find that I stumbled upon. Thesauruses are my friends. So far, I am really digging it. I figure I get one re-factoring before I hit the point of no return. I am hoping this is the right one.</p>


Naming the Patron Object

<p>I am not sure why I started using <a href="http://knockoutjs.com/">Knockout</a>, 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.</p>
<p>However, the tutorials were just an hour or two of my time, and at least got me started.  The most bothersome part is the official documentation on the website.  It is terribly incomplete, and just leads to frustration.  There are lots of hidden features and unexplained function arguments that force me to take trips through search engines, which inevitably lead to a question that someone else posted on <a href="http://stackoverflow.com/questions/tagged/knockout.js">Stack Overflow</a>, which might hint at the answer to my problem.  It has been frustrating to have to wade through the tangled mess of tangential questions and obscure answers to maybe find something similar to my problem.  However, it has also been immensely rewarding to discover new methods of working with JavaScript, better tools for debugging, and simpler ways to manage my code.</p>
<p>The <a href="https://github.com/knockout/knockout/wiki">GitHub wiki</a> is sparse and filled with many empty templates.  The information is not reliable - I am not sure how much of is it accurate as of Knockout 3.1.  So, I am working on slowly putting together better documentation.  As I discover something new or expand on something I already know, I am adding it all to a little sidebar of notes that I keep.  My hope is that I will get enough information that I can meaningfully contribute to the wiki.  I like this project, and it is clear that plenty of other people like it.  I just wish the difficulty to realistically get started was a little lower.</p>
<p>I am trying - this is going to be my <a href="http://opensource.com/life/14/1/get-involved-open-source-2014">first little tiny toe dipping</a> in the big ocean of open source development.  We shall see how it goes.</p>


KnockoutJS Tutorials Suck (But Not As Much As the Documentation)

<blockquote>
<p>The <a href="http://www.asp.net/identity">ASP.NET Identity</a> 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.</p>
</blockquote>
<p>In and of itself, it is a very nice and pleasant library that really does integrate nicely into a WebAPI or MVC project.  The template project that comes with VS2013 spins up very quickly and provides the illusion of something that the developer can just forget about.  Were that the case, I would not have this post.</p>
<p>All I wanted was to change the default primary key from a <code>GUID</code> to an int.  My initial thought was to change the default <code>ApplicationUser</code> from inheriting from the non-generic IdentityUser to the generic <code>IdentityUser&#x3C;int, VigilUserLogin, VigilUserRole, VigilUserClaim></code>.  Compiling worked just fine, running caused all kinds of type casting problems.  Why?  Because all of the other classes surrounding the <code>IdentityUser</code> were all coded to the <code>string</code> type (which internally is a <code>GUID</code>).</p>
<p>Thus began the big hunt to find out all of the places where I needed to override, inherit, or otherwise manipulate the library to get the primary key to be an integer. This meant replacing the five main classes that create the authentication and authorization schema:</p>
<ul>
<li>IdentityUser</li>
<li>IdentityRole</li>
<li>IdentityUserRole</li>
<li>IdentityUserClaim</li>
<li>IdentityUserLogin</li>
</ul>
<p>Then I had to create a new <code>UserStore</code> and <code>UserManager</code> to utilize these new classes, and create a new <code>ClaimsPrincipal</code> to store and retrieve the new security identifier (Sid) for the user. Finally, a new <code>BaseController</code> class was created that all other controllers must inherit from, in order to utilize all of this new code.</p>
<pre><code>using System;
using System.Security.Claims;
using System.Web.Mvc;
using Vigil.Data;

namespace Vigil.Web.Controllers
{
    public abstract class BaseController : Controller, IDisposable
    {
        public VigilClaimsPrincipal CurrentUser
        {
            get { return new VigilClaimsPrincipal((ClaimsPrincipal)this.User); }
        }
        protected readonly IVigilContext VigilContext = new VigilContext();

        public BaseController() { }

        protected override void Dispose(bool disposing)
        {
            if (disposing &#x26;&#x26; VigilContext != null)
                VigilContext.Dispose();
            base.Dispose(disposing);
        }
    }
}
</code></pre>
<pre><code>using System.Data.Entity;
using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.EntityFramework;
using Vigil.Data;
using Vigil.Data.System;

namespace Vigil.Web
{
    public interface IVigilUserStore : IUserStore&#x3C;VigilUser, int> { }

    public class VigilUserStore : UserStore&#x3C;VigilUser, VigilRole, int, VigilUserLogin, VigilUserRole, VigilUserClaim>, IVigilUserStore
    {
        public VigilUserStore() : base(new VigilContext()) { }
        public VigilUserStore(DbContext context) : base(context) { }
    }

    public class VigilUserManager : UserManager&#x3C;VigilUser, int>
    {
        public VigilUserManager() : this(new VigilUserStore(new VigilContext())) { }
        public VigilUserManager(IVigilUserStore store) : base(store) { }
    }
}
</code></pre>
<pre><code>using System;
using System.Security.Claims;
using Vigil.Data;
using Vigil.Data.System;

namespace Vigil.Web
{
    public class VigilClaimsPrincipal : ClaimsPrincipal
    {
        public VigilClaimsPrincipal(ClaimsPrincipal principal) : base(principal) { }

        public int UserId
        {
            get { return Int32.Parse(this.FindFirst(ClaimTypes.Sid).Value); }
        }

        public VigilUser VigilUser
        {
            get { return (new VigilContext()).Set&#x3C;VigilUser>().Find(UserId); }
        }
    }
}
</code></pre>
<pre><code>using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.Entity.ModelConfiguration.Conventions;
using System.Data.Entity.Validation;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNet.Identity.EntityFramework;
using Vigil.Data.System;

namespace Vigil.Data
{
    public interface IVigilContext : IDisposable
    {
        DbChangeTracker ChangeTracker { get; }
        DbContextConfiguration Configuration { get; }
        Database Database { get; }
        DbEntityEntry Entry(object entity);
        DbEntityEntry&#x3C;TEntity> Entry&#x3C;TEntity>(TEntity entity) where TEntity : class;
        IEnumerable&#x3C;DbEntityValidationResult> GetValidationErrors();
        int SaveChanges();
        Task&#x3C;int> SaveChangesAsync();
        Task&#x3C;int> SaveChangesAsync(CancellationToken cancellationToken);
        DbSet&#x3C;TEntity> Set&#x3C;TEntity>() where TEntity : class;
        DbSet Set(Type entityType);
    }
    public class VigilContext : IdentityDbContext&#x3C;VigilUser, VigilRole, int, VigilUserLogin, VigilUserRole, VigilUserClaim>, IVigilContext
    {
        public VigilContext()
            : base("VigilDb")
        {
            Database.SetInitializer&#x3C;VigilContext>(new VigilDbInitializer());
        }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.HasDefaultSchema("vigil");
            modelBuilder.Conventions.Remove&#x3C;OneToManyCascadeDeleteConvention>();
        }
    }
}
</code></pre>
<pre><code>using Microsoft.AspNet.Identity;
using Microsoft.AspNet.Identity.EntityFramework;

namespace Vigil.Data.System
{
    public class VigilUser : IdentityUser&#x3C;int, VigilUserLogin, VigilUserRole, VigilUserClaim>, IUser&#x3C;int>
    {
    }
    public class VigilRole : IdentityRole&#x3C;int, VigilUserRole>, IRole&#x3C;int>
    {
    }
    public class VigilUserRole : IdentityUserRole&#x3C;int>
    {
    }
    public class VigilUserLogin : IdentityUserLogin&#x3C;int>
    {
    }
    public class VigilUserClaim : IdentityUserClaim&#x3C;int>
    {
    }
}
</code></pre>
<p>At this point, I am wrestling with the fact that now my domain model has a hard requirement on the <code>Microsoft.AspNet.Identity</code> library. I had initially hoped to have my <code>User</code> and <code>Role</code> domain models be completely separated from the actual authentication/authorization system. This creates a hard link that is going to be the death of me unless I can find a way to isolate the framework and run unit tests without requiring the database. For now, though, I am going to continue in this direction, and turn a blind eye to the technical debt accruing from this decision. Maybe before I ship this, I will find a better way to do it all, but for now at least I have my integers.</p>


Rovani's Sandbox

Blog Posts - Page 12