LINQ library – Part 4

Last time we walked through the EntityFrameworkUnitOfWorkStrategyBase class, and saw how it implements the behaviors that are common to any flavour of Entity Framework database strategy, whether that be for SQL-Server, SQL-Lite, or in-memory. This time, we’ll see how the library creates concrete strategy classes by deriving from EntityFrameworkUnitOfWorkStrategyBase.

The concrete strategy that implements SQL-Server behavior is called SqlServerUnitOfWorkStrategy. The trimmed down source for that class is shown here:


Not much code here, is there? That’s the nice thing about object-oriented software, things get simpler as they progress …

So, this class obviously derives from the EntityFrameworkUnitOfWorkStrategyBase class, as we said before. It contains a single constructor, which is where we create the database context and assign it to the Context property on the base class. To do that, we start by creating an options builder object, then we call the UseSqlServer metod on that object, to tell EF that we’re going to be connecting to a SQL-Server database. Then we plug in a connection string from our setup. Finally, we use the activator to create an object of type TContext (which is constrained to be a type of DbContext). We pass in the database options to the constructor of the TContext object to pull everything together.

Which brings us to another convention …

Any DbContext created by this strategy will need to have a public constructor on it that accepts a parameter of type DbContextOptions. That’s because we need to tell EF what kind of database it will be connecting to, and this is the easiest way to do that. Another way would have been to have the database context class override the OnModelCreating method, and assume it would properly set everything up there, but I don’t know of any way to enforce any of that using C#, and let’s face it, at some point, using that approach, we would have gone from a convention to a full-blown protocol – one that would no doubt have been violated more often than not.

So, we have a convention that the TContect type has to include a public ctor. Something good to know. Also, this convention only affects Entity Framework specific strategy types, for obvious reasons.

The SqlServerUnitOfWorkStrategy class is supported by the SqlServerUnitOfWorkProvider class. The trimmed down source for that class is shown here:


There is also a corresponding setup type, called SqlServerUnitOfWorkStrategySetup, that looks like this:


There is also an extension method that adds the setup to a LinqUnitOfWorkBuilder class. The source for that looks like this:


So how do we pull all of this together? Let’s go back and look at the example code I created in previous articles, except that we’ll fill in the missing piece now to create working code:


So, this time we added the bit where we call the AddSqlServerProvider method, then plug in a connection string. That little bit of code injects a configured SqlServerUnitOfWorkSetup object into the builder’s setup collection. At build time, the builder then creates a SqlServerUnitOfWorkProvider object, which then returns our SqlServerUnitOfWorkStrategy object to the unit-of-work product.

If you’re not familiar with my use of the Builder design pattern, here’s a link to an article I wrote about it:


The code for this article is part of my NUGET packages CG.Linq.Entity.Framework and CG.Linq.EntityFramework.SqlServer, which can be downloaded for free here:


The source code for the CG.Linq.EntityFramework and CG.Linq.EntityFramework.SqlServer packages live on Github and can be obtained for free here:


Next time I’ll wrap things up with a quick discussion of my other two Entity Framework database strategy types. Until then!


Photo by KS KYUNG on Unsplash