LINQ library – Part 5

Last time I covered the internals of my SQL-Server unit-of-work strategy. I also demonstrated how that strategy could be plugged into a unit-of-work using a working bit of example code.

This time I’ll quickly cover my SQL-Lite and in-memory strategies.

The trimmed down source code for my My SQL-Lite unit-of-work strategy is shown here:


Just like last time, with the SQL-Server strategy, this one derives from the EntityFrameworkUnitOfWorkStrategyBase class. That means this class shares most of it’s implementation with the SQL-Server strategy. In fact, the only thing that’s any different is the constructor, where we call the UseSqlLite method on the options builder, rather than the UseSqlServer method we called for the SQL-Server strategy.

Otherwise, everything else is the same. Same convention for the TContext class as last time, where we expect the class to contain a public constructor that accepts a DbContextOptions object as a parameter.

In fact, the in-memory strategy class looks suspiciously familiar at this point …


Yes, that’s right, this class only differs from the other two in the way we configure the options builder. For this one, we also supply an optional database name from our setup, but other than that, really not much different than the SQL-Server of SQL-Lite version. Of course, the reason that’s true is that I’m only wrapping an existing library from Microsoft and they did such a great job of designing it that all I needed to do was change the way the options were constructed.


Thanks for that, Microsoft.


There are provider and setup classes that go with these two strategy classes, but, I’ve presented provider and setup classes before and these aren’t appreciably different than those, so, I’ll refrain from including the source for them here. If you’re interested though, the source is part of the CG.Linq.EntityFramework.SqlLite and CG.Linq.EntityFramework.InMemory NUGET packages. The source and the binary are both available online here:



When pulled together, the code that I’ve presented in the last five articles creates a thin CRUD layer that allows the database specific portions of a repository class to take advantage of any number of different database technologies – without having to rewrite the repository class for each new flavour. The abstraction at the center of the library is a unit-of-work, which then uses any number of pluggable strategies at runtime to supply database specific behavior to the unit-of-work.

The libraries are easy to use and easy to extend. I’ve personally used them on a wide variety of projects using technologies such as: SQL-Server, AWS, Azure, Oracle, MySql, MongoDb, CouchDb, JSON files, XML files, and more.

If you’re still reading at this point then I hope you’ve enjoyed the articles. Have fun with the code!


Photo by Murray Campbell on Unsplash