Entity Framework

EF6 Extensibility and Configuration


I just published two posts to the Entity Framework CodePlex site that cover some changes we are making to EF6 to improve extensibility and code-based configuration. These posts provide conceptual overviews of the features with relevant design and implementation details. The idea is that people who are interested in where EF is going can read posts like this and provide feedback on the direction, design, and implementation. Providing this kind of feedback is an important way to contribute to EF without even having to write any code.

Overview and goals

EF has historically taken a rather ad-hoc approach to runtime configuration and extensibility. The changes for EF6 described in these posts are intended to replace this ad-hoc approach with some building blocks that will provide a common mechanism for configuration. In doing so they also allow EF to be more easily extended by extracting out services that can then be resolved to different implementations at runtime.

In particular, the changes have the following high-level goals:

  • Provide a common mechanism and building blocks whereby aspects of existing EF functionality can be factored out or new functionality added in such a way that different implementations can be injected without the core EF code knowing about the specifics of these implementations.
  • Provide a unified mechanism for EF code to access configuration regardless of whether that configuration has been set in code (“code-based”) or in the application’s config file.
  • Ensure that configuration can be discovered by design-time tools such that actions such as running the Code First pipeline can be correctly performed by tools.
  • Allow, but not require, EF dependencies to be injected using the application developer’s Inversion-of-Control (IoC) container of choice.

Dependency resolution

The first post describes the new IDbDependencyResolver interface that allows EF to be configured and extended by resolving services that it depends on. The approach is based loosely a similar mechanism in MVC and Web API and makes use of the Service Locator pattern but with important modifications that address some of the issues with that pattern.

The dependency resolution design allows for an IoC container to be used with EF but does not require it or prescribe which one. We will publish another post providing an example of how to use an IoC container with EF.

Code-based configuration

The second post describes the new DbConfiguration class that allows all configuration to be made in code while still allowing design-time tools to find and use this configuration. This is important when using Code First because design-time tools often need to know about the EF model, but this cannot be built correctly without also knowing how EF has been configured.

The code-based configuration also allows application developers to configure EF without needing to learn anything about dependency resolvers, even though these are the underlying building blocks on which the configuration is based. This is important for keeping the concept count low for developers just getting started with EF.

Feedback, please!

The reason we spend time writing this stuff and putting it out there is so that you can tell us what you think before it gets into a shipped product and becomes hard to change. Regardless of whether you love it, hate it, or think it’s pointless, please do let us know!

Categories: Entity Framework, Extensibility, Open Source

Tagged as: ,

5 replies »

  1. Hi. Slightly off topic because it’s about EF5, but not sure where to ask: I’m trying to get my EF Designer extension, which works in VS 2010, to work in VS 2012. I updated all references and can’t seem to get it to work. Can you tell me where I can get an example of a designer extension that will work in 2012?

  2. Are you doing any work on Designer extensions? I would like to see more work done to make it easier to extend the designer. I like to add properties to entities/properties to drive all kinds of T4 scenarios – repository classes, custom DTOs. Btw, I can’t find anything about making extensions work even in EF5 / VS 2012 – can you tell me some resources that would help? I’ve got one that works in 2010 but can’t get it to work in 2010, and there seems to be almost no support for that out there. Anything you can provide is much appreciated!

  3. I have a question on code-based configuration I was hopping for you to comment on.

    We are using a DbConfiguration class that sets the execution strategy for SQL Azure using some app settings to control retries and max retry delay. These settings are provided via an interface dependency but we do not know the exact type or location of the settings by design. Usually IServiceConfiguration is a constructor parameter to classes that need it:
    public RuleRepository(IServiceConfiguration configuration)

    We are however having a great deal of trouble figuring out how to access these settings from the DbConfiguraion constructor without resorting to a service lookup. Our DbConfiguration is the only class in the whole solution resorting to service lookup so we are hoping to avoid it if we can.

    public MyDbConfiguration(/*IServiceConfiguration serviceConfiguration*/)
    //TODO: How the heck do I get an instance of IServiceConfiguration into here without resorting to a service lookup.

    int maxRetryCount = 8;
    TimeSpan maxRetryDelay = TimeSpan.FromSeconds(10);

    var resolver = System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver;
    if (resolver != null)
    var serviceConfig = (IServiceConfiguration)resolver.GetService(typeof(IServiceConfiguration));

    if (serviceConfig != null)
    maxRetryCount = serviceConfig.MaxRetryCount;
    maxRetryDelay = TimeSpan.FromSeconds(serviceConfig.MaxRetryDelaySeconds);

    SetExecutionStrategy(“System.Data.SqlClient”, () => new SqlAzureExecutionStrategy(maxRetryCount, maxRetryDelay));