EF7 Provider Building Blocks

In this post I’ll outline the basic building blocks needed for an EF7 provider. The idea is not to show how everything should be implemented, but rather to show what pieces are needed and how they fit together. The best examples of EF7 providers are the SQL Server and SQLite providers, which ca both be found in the EF repro on GitHub.

EF7 providers should be shipped as NuGet packages. This post does not cover NuGet packaging, but you can look at the GitHib repro for some ideas on how to do this.

Note that EF7 is still very much pre-release software and the types and APIs described here are likely to change as we evolve towards the RTM release.

Dependency Injection

EF7 makes extensive use of dependency injection (DI). That is, EF is a collection of services that work together and depend on each other largely through constructor injection. Implementing an EF provider is really a matter of creating provider-specific implementations of these services as needed.

Context scopes

A single EF7 application can make use of multiple providers. For example, the same application could access a SQL Server database and a SQLite database. However, the session defined by each context instance is restricted to using a single provider. So you can create one context instance to access SQL Server and another context instance to access SQLite, but you cannot create one context instance and access both SQLite and SQL Server with that single instance.

This is achieved through each context instance creating a new DI scope. Services for the provider in use are then resolved through that scope using the mechanisms outlined in this post.

Types of services

EF7 has three broad categories of services:

  • Core services, which are not intended to be implemented differently for different providers.
  • Provider-specific services for which there are no common concrete implementations. All providers must provide implementations of these services. However, there are often abstract base classes that can be used as the basis for provider-specific implementations.
  • Provider-specific services for which there are common concrete implementations. For these services, a provider only needs to provide an implementation if the common implementation needs to be changed in some way.


As stated above, the selection of which provider to use for a given context instance is done by creating a new DI scope. Provider-specific services are then resolved for the scope using delegates that map from the contract interface to the provider-specific implementation. This mapping is done using an implementation of the IDataStoreServices interface, and therefore each provider must create its own implementation of this interface and register it with DI.

For relational providers there is an IRelationalDataStoreServices interface which adds additional services used by the EF7 relational infrastructure. Providers that connection to a relational database should implement this interface.

There are base implementations of IRelationalDataStoreServices and IDataStoreServices (called RelationalDataStoreServices and DataStoreServices respectively) that contain predefined mappings for provider-specific services for which there are common concrete implementations. Providers should generally use one of these base classes and only override virtual methods as needed.

For example, here is the implementation of IRelationalDataStoreServices used by the SQLite provider, as of the time of writing:

public class SqliteDataStoreServices : RelationalDataStoreServices
    public SqliteDataStoreServices(IServiceProvider services)
        : base(services)

    public override IDataStoreConnection Connection 
        => GetService<SqliteDataStoreConnection>();

    public override IDataStoreCreator Creator 
        => GetService<SqliteDataStoreCreator>();

    public override IHistoryRepository HistoryRepository 
        => GetService<SqliteHistoryRepository>();

    public override IMigrationSqlGenerator MigrationSqlGenerator 
        => GetService<SqliteMigrationSqlGenerator>();

    public override IModelSource ModelSource 
        => GetService<SqliteModelSource>();

    public override IRelationalConnection RelationalConnection 
        => GetService<SqliteDataStoreConnection>();

    public override ISqlGenerator SqlGenerator 
        => GetService<SqliteSqlGenerator>();

    public override IDataStore Store 
        => GetService<SqliteDataStore>();

    public override IValueGeneratorCache ValueGeneratorCache 
        => GetService<SqliteValueGeneratorCache>();

    public override IRelationalTypeMapper TypeMapper 
        => GetService<SqliteTypeMapper>();

    public override IModificationCommandBatchFactory ModificationCommandBatchFactory 
        => GetService<SqliteModificationCommandBatchFactory>();

    public override ICommandBatchPreparer CommandBatchPreparer 
        => GetService<SqliteCommandBatchPreparer>();

    public override IRelationalDataStoreCreator RelationalDataStoreCreator 
        => GetService<SqliteDataStoreCreator>();

Notice that it derives from RelationalDataStoreServices to use common services where possible and overrides for all services where a custom implementation is required.

Also notice that each property is mapping a concrete type in the GetService call to the contract interface that other services will depend on. That is, services should take the contract interface, not the concrete implementation, in their constructors so that all services are programmed against the contracts of other services.

Registering services

Each of the concrete services must be registered in the DI container so that the GetService calls will have something to find. This is done in an AddXxx extension method, where Xxx is the name of the provider. For example, the extension method for SQLite looks like this:

public static EntityFrameworkServicesBuilder AddSqlite(
    this EntityFrameworkServicesBuilder services)
        .AddSingleton<IDataStoreSource, SqliteDataStoreSource>()
        .TryAdd(new ServiceCollection()

    return services;

The AddXxx method is an extension method on EntityFrameworkServicesBuilder and should return the EntityFrameworkServicesBuilder that is passed in. This allows it to be chained from an AddEntityFramework call when registering DI services and allows additional AddXxx methods to be chained from it.

For a relational provider, a call To AddRelational is required to add all common relational services.

The registration of an IDataStoreSource facilitates selection of a given provider as described below. The remaining calls register the concrete services that will be resolved by the provider’s IDataStoreServices implementation.

Registration scopes

In most cases provider-specific services should be registered in DI as “scoped” using AddScoped. This is because the context creates scopes in order to use different providers for different context instances. Also, any service that depends on a scoped service must itself be registered as scoped.

In a few cases services can be registered using AddSingleton where the service does not depend on any other scoped service and a single instance can be used concurrently by all context instances–for example, the SqliteSqlGenerator in the code above. Note that all singleton services must be thread-safe.

There are currently two services (IModelSource and IValueGeneratorCache) which act as provider-specific caches. These services must be registered as singletons so that the cache persists across context instances, which is the point of having the cache. They therefore cannot depend on any scoped services. Also, each provider must use its own concrete implementation for these services so that each provider gets a different instance and cache collisions are avoided.

Provider selection

EF7 applications choose which provider to use for a given context instance my making a call to a UseXxx method, typically in the OnConfiguring method of the context. For example, to use SQLite an application might do something like this:

protected override void OnConfiguring(
    DbContextOptionsBuilder optionsBuilder)

The UseSqlite method is an extension method on DbContextOptionsBuilder. Its job is to create (or update an existing) IDbContextOptionsExtension object and register it onto the options builder. For example:

public static SqliteDbContextOptionsBuilder UseSqlite(
    this DbContextOptionsBuilder options,
    string connectionString)
    var extension = GetOrCreateExtension(options);
    extension.ConnectionString = connectionString;

    return new SqliteDbContextOptionsBuilder(options);

Note that a new builder with the updated options is returned to allow chaining of further configuration.

Presence of IDbContextOptionsExtension in the options builder is used by the EF stack to determine that a provider has been selected. It is also used to store provider-specific configuration for the session. Some of this configuration, like the connection string, is handled by the relational base class.

An IDbContextOptionsExtension is also used to register DI services automatically for the case where EF is taking care of all DI registration internally. An example implementation for SQLite (trimmed) looks something like:

public class SqliteOptionsExtension : RelationalOptionsExtension
    public override void ApplyServices(
        EntityFrameworkServicesBuilder builder)
        => builder.AddSqlite();

When EF needs to register the current provider’s services it calls ApplyServices, which in turn calls the AddXxx extension method that was defined above.


The final piece of the puzzle that connects selection of a provider with the services used for that provider is an implementation of the IDataStoreSource interface. A typical implementation uses the DataStoreSource generic base class, passing in the types for the provider’s IDataStoreServices and IDbContextOptionsExtension implementations. For example, SqliteDataStoreSource looks something like:

public class SqliteDataStoreSource 
    : DataStoreSource<SqliteDataStoreServices, SqliteOptionsExtension>
    public override void AutoConfigure(DbContextOptionsBuilder optionsBuilder)

    public override string Name => "SQLite Data Store";

SqliteDataStoreSource is then registered in the AddSqlite extension method as shown above.

All of this means that when EF finds that a SqliteOptionsExtension has been added to the options builder through a call to UseSqlite, then SqliteDataStoreServices will be used to resolve services for the scope of that context instance.


The steps for creating an EF7 provider are:

  • Implement provider-specific services, using IDataStoreServices and IRelationalDataStoreServices as a guide for the services needed
  • Create an implementation of IDataStoreServices or IRelationalDataStoreServices to map your implementations, using one of the base classes as a starting point
  • Create an AddXxx extension method to register your services in DI
  • Create an IDbContextOptionsExtension implementation to handle provider selection and configuration
  • Create a UseXxx extension method to allow applications to select your provider
  • Create an IDataStoreSource implementation to tie everything together

Of course, the hard part about creating any provider is actually implementing the services. Also, you will likely want to create some extension methods for provider-specific model building and/or runtime functionality. If there is enough interest I may blog about these things at a later date.

Posted in EF7, Entity Framework | Tagged , | Leave a comment

Lego Mindstorms 360° Photobot for Gear VR

I found this video a week or so ago showing how to create 360° spherical photos that can be viewed in the Samsung/Oculus Gear VR. It works nicely, but it is both tedious and error-prone trying to manually capture all the images needed for a full spherical picture. I figured it would be much more convenient if something could automatically move the camera appropriately. Enter the Lego Mindstorms 360° Photobot for Gear VR!

The Photobot

The Photobot

This video on YouTube shows how it works. It’s not perfect–you can definitely see the stitching, especially on photos of relatively small spaces.

Here’s a sample photo of me and my daughter playing Minecraft taken using the photobot. (Yes, the room is a complete mess. I’ve been playing with Lego instead of being a grown-up!)

360° Photo for Gear VR

Sample 360° Photo for Gear VR taken using the Lego Photobot

This photo also shows something else that the photobot enables–being in your own 360° picture. The selfie-360 is born!

Now, what I would really love to do is capture 360° stereo photos! The sense of space is pretty decent without stereo, but stereo would certainly add a lot to the effect, especially for small spaces.

Posted in Virtual Reality | Leave a comment

The future of Virtual Reality is not gaming…

It is starting with games, games are a great fit, and the games are going to be awesome. But it will become huge through immersive sports, immersive music, and most importantly, immersive storytelling.

Why? Because regardless of technology by far the most popular entertainments are ones that people can enjoy passively. Many more people regularly watch sports than play sports. Many more people enjoy music performances than play music. Many more people read books, watch TV, and go to the movies than play video games.

But why is VR such an advance for these experiences? Because all these things to some degree take us out of our normal existence and transport us to a different world. Anyone who has tried the primitive 360-degree experiences available on the Oculus Rift or Gear VR knows that Virtual Reality takes this to the next level.

Example: sports

With VR you will be able to get a court-side seat at a basketball game without leaving your home. In a very real sense VR with presence will make it feel like you are there. It won’t be the same as going to the game because there is so much more about going to a game than being at the game. Going to a game is a social outing, and social outings will remain. But it will be at an entirely different level than watching on TV.

Example: music

VR will transport you to the concert arena where you can experience an awesome concert complete with fully immersive lighting, pyrotechnics, lasers, etc. For music VR also gives something more–the ability to be up-close with the greats in a way that is just not possible for the vast majority of us in the real world.

Example: Storytelling

Storytelling has been the killer app for human entertainment throughout history. Storytelling is fundamentally about transporting us to other worlds. Plays, books, cinema, and TV all do this. Using VR you can be with David Attenborough anywhere in the world as he unfolds nature’s story. You can go into things, even at microscopic scale. Or at larger scale Brian Cox can weave a tail of the stars while you float in space next to an exploding supernova.

But these real worlds are just the tip of the iceberg. Peter Jackson could take us into Middle Earth. Not just seeing it through a window, but actually being immersed in it with splendor of Rivendell unfolding on all sides. With presence you will really feel like you are there. Imagine Gollum creeping up behind you. Or raising your head up to see Barad-dûr towering its immensity with the eye of Sauron burning its gaze upon you. This will happen. You will be there. It will be awesome.

It is coming…

There are many technical and creative challenges ahead–especially when it comes to storytelling. We don’t yet know the best way for stories to unfold when the listener/viewer/experiencer is immersed in the world of the story. Transformative technologies are like this–the first movies were essentially filmed plays. But we quickly understood how to use moving pictures to tell stories and we will do the same with VR.

Also, the social aspect has to be incorporated, and we don’t really know how to do that yet. I want to go to the game with my friends, but exactly what that means remains to be seen.

Despite these issues things are moving fast. Very fast. The universe is about to expand. In a very real sense we are about to enter the age of the multiverse–virtual universes will start popping into existence and we all get to visit them. Sit back and enjoy. You will be awed.

Posted in Virtual Reality | Tagged , | Leave a comment

How Magic Leap redefined magic. Literally.

There has been huge excitement at the long awaited announcement that Harry Potter will be reinvented in Cinematic Reality. Despite this excitement some truly die-hard fans are angry. Why? Because Harry, Hermione, and Ron won’t be using magic; they will be using sorcery.

To understand why, we must go back nearly 15 years to the summer of 2015 when Magic Leap exploded into the world’s consciousness. I had tried Oculus VR and it was stunning, but nothing prepared me for my first Magic Leap experience. I was so excited on my first first trip to the Magic Shop to see the Flutterpods. My first purchase? A dragon, of course! His name is Tarquin and he’s perched on my bookcase right now, cleaning his wings. It was clear to me at that moment that Magic Leap had invented magic. So along with everyone else I began calling this new technology just that: magic.

The speed with which magic became ubiquitous is, of course, well known. I’m writing this sitting on my couch with a translucent writing screen conveniently floating in front of me. When my daughter Magic-Skyped in a few minutes ago the screen faded away and instead she was there in the room with me. We magiced in her mom as we planned for Thanksgiving. When done they magiced away and I magiced the writing screen back up with a nod of my head. Remember all those devices that we used to have–phones, TVs, tablets, laptops? They are all pretty much obsolete now. Everyone just uses magic.

And this is the problem for Harry Potter. For the generation that has grown up with magic it becomes confusing when characters are engaging in the fictional supernatural phenomenon that is now commonly known as sorcery, but are referring to it as “magic”. Personally, I think the younger generation should be given enough credit to understand that Harry Potter comes from the time before magic. I don’t expect Hollywood to agree with me.

The redefinition of words by technology is nothing new. Consider that the word “computer” originally referred to a person who would perform computations. But if I say, “the time before computers” everyone understands I am not talking about such people. Likewise, when I say, “the time before magic” most people will understand what that means–it means the time before Magic Leap.

Magic has its problems and everyone is aware that not all the social implications have been positive. But despite these issues I feel extremely lucky to be living in the age of magic. And as I throw snacks for Tarquin and watch him swoop down to pluck them out of the air I want to say a big thank you to Magic Leap for inventing magic. And yes, magic was invented in the same way that computers were invented. It was invented so completely that the very word has been redefined. Literally.

Posted by Arthur
November 22, 2029.

(This is a work of speculative fiction. I have no connection to Magic Leap nor do I have any inside information. I am not from the future.)

Posted in Entity Framework | Leave a comment

After wearing ourselves out in the real world, my daughter and I…

Today, after wearing ourselves out in the real world, my daughter and I have paddled down the Anduin and through the Argonath, floated in space above the Earth, flown through the Solar System and marveled at the beauty of Saturn’s rings, watched some of The Lego Movie in 3D on a giant theater screen, caused asteroids to explode by staring at them, shot paper balls around a classroom and played a Game Boy under the desk, until the game came out of the Game Boy and filled the classroom, sat in a cafe in Paris as a robot, enjoyed butterflies fluttering around us and petals floating softly from above, ridden a roller coaster through a lava factory, and flown inside our own Minecraft worlds. This is just the beginning. Thank you Oculus. Everything is awesome.

Posted in Entity Framework | Leave a comment

Soft Oatmeal Cookies

How software engineers make cookies, or a true story about over thinking everything… Continue reading

Posted in Entity Framework | 1 Comment

EF 6.1: Creating indexes with IndexAttribute

Since EF 4.3 it has been possible to use CreateIndex and DropIndex in Code First Migrations to create and drop indexes. However this had to be done manually by editing the migration because the index was not included anywhere in the Code First model. Now with EF 6.1 it is possible to add index specifications to the model such that creating and dropping indexes can be handled automatically by Migrations. Continue reading

Posted in Code First, Code First Migrations, Data Annotations, Entity Framework | Tagged , , , , , | 23 Comments