entityframework Wiki Rss Feed

Updated Wiki: specs

RoMiller — Thu, 23 May 2013 22:00:40 GMT

Entity Framework 6

As we work on EF6 we will be creating feature specifications, walkthroughs and other documentation.

Runtime

Here is a list of the new features in the EF6 runtime and the documentation we have created for them.

Async Query and Save adds support for the task-based asynchronous patterns that were introduced in .NET 4.5. We've created a walkthrough and a feature specification for this feature.
Custom Code First Conventions allow write your own conventions to help avoid repetitive configuration. We provide a simple API for lightweight conventions as well as some more complex building blocks to allow you to author more complicated conventions. We’ve created a walkthough and a feature specification for this feature.
Code First Mapping to Insert/Update/Delete Stored Procedures is now supported. We’ve created a feature specification for this feature.
Connection Resiliency enables automatic recovery from transient connection failures. The feature specification shows how to enable this feature and how to create your own retry policies.
Dependency Resolution introduces support for the Service Locator pattern and we've factored out some pieces of functionality that can be replaced with custom implementations. We’ve created a feature specification and a list of services that can be injected.
Code-Based Configuration gives you the option of performing configuration – that was traditionally performed in a config file – in code. We've created an overview with some examples and a feature specification.
Interception/SQL logging provides low-level building blocks for interception of EF operations with simple SQL logging built on top. We've created a feature specification for this feature and Arthur Vickers has created a multi-part blog series covering this feature.
Configurable Migrations History Table allows you to customize the definition of the migrations history table. This is particularly useful for database providers that require the appropriate data types etc. to be specified for the Migrations History table to work correctly. We’ve created a feature specification for this feature.
Multiple Contexts per Database removes the previous limitation of one Code First model per database when using Migrations or when Code First automatically created the database for you. We’ve created a feature specification for this feature.
DbModelBuilder.HasDefaultSchema is a new Code First API that allows the default database schema for a Code First model to be configured in one place. Previously the Code First default schema was hard-coded to "dbo" and the only way to configure the schema to which a table belonged was via the ToTable API.
Enums, Spatial and Better Performance on .NET 4.0 - By moving the core components that used to be in the .NET Framework into the EF NuGet package we are now able to offer enum support, spatial data types and the performance improvements from EF5 on .NET 4.0.
DbContext can now be created with a DbConnection that is already opened which enables scenarios where it would be helpful if the connection could be open when creating the context (such as sharing a connection between components where you can not guarantee the state of the connection).
Default transaction isolation level is changed to READ_COMMITTED_SNAPSHOT for databases created using Code First, potentially allowing for more scalability and fewer deadlocks.
DbContext.Database.UseTransaction and DbContext.Database.BeginTransaction are new APIs that enable scenarios where you need to manage your own transactions.
Improved performance of Enumerable.Contains in LINQ queries.
Significantly improved warm up time (view generation) – especially for large models – as the result of a contribution from AlirezaHaghshenas.
DbModelBuilder.Configurations.AddFromAssembly method was contributed by UnaiZorrilla. If you are using configuration classes with the Code First Fluent API, this method allows you to easily add all configuration classes defined in an assembly.
Custom Migrations Operations were enabled by a contribution from iceclow and this blog post provides an example of using this new feature.
Pluggable Pluralization & Singularization Service was contributed by UnaiZorrilla.
Improved Transaction Support updates the Entity Framework to provide support for a transaction external to the framework as well as improved ways of creating a transaction within the Framework. See this feature specification for details.
Improved POCO support. Entity and complex types can now be nested inside classes and can have custom implementations of Equals or GetHashCode.

Tooling

Here are the changes and features we are planning for the EF6 tooling.

The Basics covers things that aren’t classified as features but are required to provide a good tooling experience. Topics include branding, installation, supported VS versions, supported EF versions, etc.
Tooling Consolidation will combine the EF Power Tools and the EF Designer to provide a single set of tooling with a single wizard for creating new models. We’ve created a feature specification for this feature.

Entity Framework 5

The EF5 release was largely completed prior to moving to CodePlex, these documents only include the final set of changes made in EF5.

Backlog

These documents are for features that have not yet been assigned a release.

New Comment on "Code First Insert/Update/Delete Stored Procedure Mapping"

trageley — Wed, 22 May 2013 14:24:06 GMT

Is it possible (or will it be possible) to provide a stored procedure parameter that is not a property on the entity? We have stored procedures that take in an additional parameter for the current user id for logging purposes. Thanks!

New Comment on "Improved Transaction Support"

michaelelfial — Tue, 21 May 2013 22:09:37 GMT

I don't think the factories will be a good replacement. I am trying to embed EF as part of a framework that keeps its own context with database(s) and tracks transactions on them - without this EF6 addition I was dead in the water! The problem is it is extremely inconvenient to use ambient transactions (not even considering the additional dependencies) and the fact that the framework in question manages longer-living contexts - i.e. there are no using { } blocks there - instead it takes care for the disposal of everything at the right stages and the developer can access or auto open (connections) auto start (transactions) from different points in a complex pipeline. So, without a way to attach the EF context to the transaction it seems that my options are not pretty.

New Comment on "Roadmap"

niico — Tue, 21 May 2013 20:38:06 GMT

+1 for 'Unique constraints/alternate/natural keys' - [Unique] data annotation on models please!

New Comment on "Documentation"

huoxudong125 — Fri, 17 May 2013 09:57:19 GMT

when i build the whole solution,i can't find any tests in test explorer, i have install the xunit for vs2012(with sp2). who can give me a hand?thanks

Updated Wiki: Design Meeting Notes

ajcvickers — Fri, 17 May 2013 02:14:32 GMT

Entity Framework Design Meeting Notes

The Entity Framework team has a weekly design meeting in which we discuss/recap design and other issues with the codebase. These are the notes from those meetings. The intention is to provide a history of what decisions have been made and why. No attempt is made to go back and update notes from older meetings if we later change a decision and decide to do something different.

May 16, 2013

Time format in DbCommandLogger
Potential breaking change to IDbSet
Conversion to lightweight conventions

May 9, 2013

Interception building blocks
DbContext.Database.Log

April 11, 2013

Default providers
- The default connection factory
- Default provider configuration
- Additional config file elements
- DbProviderServices methods
Model-based conventions exploratory testing

April 4, 2013

Revisit: Using ExecuteSqlCommand without a transaction
Revisit: Extension method class naming
New transient error codes

April 2, 2013

API Review: Multiple Contexts per Database
API Review: Configurable Migrations History Table

March 28, 2013

Rename of DbExtensions to IQueryableExtensions
Pattern for customizing migrations history table
Turning off automatic transaction creation
Buffering in EntityClient

March 21, 2013

Missing property handling in lightweight conventions
Code First stored procedure mapping

March 19, 2013

Connection Resiliency Review

March 18, 2013

Async Query & Save API Review

March 14, 2013

File/code-based configuration precedence

March 13, 2013

Custom Code First Conventions

March 7, 2013

Custom migration operations usability
WrapService naming
Database initializers and shared databases

February 28, 2013

Models with nested types in Code First
Configuration of connection resiliency execution strategy
Behavior of disposed DbContextTransaction

February 20, 2013

Mapping to fields
Removal of unused resources

February 14, 2013

Branching for EF releases
Pull request: extending Migrations
Code First: modification function mapping API (mapping to stored procs)

February 7, 2013

DbContext and transactions (continued)
Pull request: extending Migrations
Issues with SQL Server spatial types

January 31, 2013

DbContext and transactions
Code First: modification function mapping (mapping to stored procs)

January 24, 2013

Buffering data reader perf
Provider-agnostic testing
Porting old SQL tests

January 17, 2013

Metadata API surface
Pluralization service exploratory testing feedback
Metadata unification
Porting existing SQL tests
How should pluralizers be made available?

January 10, 2013

Clustered/non-clustered unique identifier primary keys and SQL Azure

December 13, 2012

Lightweight conventions
Clustered/non-clustered unique identifier primary keys
Potential contribution for pluralization service

December 6, 2012

Additional ObjectContext and EntityConnection constructors
Default schema changes during initialization
Making EF queries buffer by default
SQL Azure connection resiliency
WET, DAMP, or DRY tests

November 29, 2012

Handling pull requests
Making READ_COMMITTED_SNAPSHOT the default
Database First WinForms data binding

November 20, 2012

Automatic EntityTypeConfiguration discovery

November 15, 2012

Lightweight conventions
View generation API
Removal of Code Contracts

November 8, 2012

Lightweight conventions
Connection resiliency to transient failures

October 25, 2012

Change default mapping for DateTime
Lightweight conventions
DbConfiguration exploratory testing
Code Contracts discussion

October 11, 2012

Lightweight conventions

October 4, 2012

Global spatial provider
Set-based configuration

September 27, 2012

Dependency resolver scoping
Sugar methods for services
Simplified API for common conventions

September 20, 2012

By-convention parameter binding SqlQuery overload
SqlCE relative path connection string UX issues with Migrations
Pluggable Conventions
Polish the conventions API
Breaking change

August 23, 2012

Make ObjectContext implement IObjectContextAdapter
Migrations multi-tenancy
Designer versioning
Async protection

August 9, 2012

Getting schema Information from providers
Using IDbDependencyResolver with existing IoC containers

August 2, 2012

CUD Batching
Bulk operations

July 26, 2012

Async
One-pagers
Initializer proposal

July 12, 2012

Model key caching
Migrations history table schema changes
Async immediate LINQ operators

July 5, 2012

Refactoring and unit tests

June 28, 2012

Code contracts

June 21, 2012

Code-based configuration

June 14, 2012

Making database connections in the test suite more configurable

June 7, 2012

Naming convention for static readonly and const fields
How will we handle breaking changes in EF6?
High-level ideas for using dependency injection with EF and specifics for the provider

May 31, 2012

Making EF code more testable
Code duplication in Async
Supporting MVC scaffolding

Updated Wiki: Design Meeting Notes - May 16, 2013

ajcvickers — Fri, 17 May 2013 02:11:40 GMT

Design Meeting Notes - May 16, 2013

Time format in DbCommandLogger

It was suggested in a CodePlex discussion that the “executing at” time in the default DbCommandLogger output should be UTC time. This was discussed and the universal feeling on the team was that in this case local time formatted to current culture is preferable. The reason for this is that the “timestamp” is not a timestamp designed to be used in the index of a log file or to be saved in an automated logging operation. It is instead a much more “conversational” log designed to produce human readable content probably of most use in debugging. As such, the local time seems more appropriate and useful. However, we will look into adding time zone info to the output to make this absolutely clear. See CodePlex 1151.

There was also discussion about whether or not the timestamp is even useful enough to include. The marginal opinion was that we should keep it, with the first person who can document a real-world case where it was useful getting a free beer.

Potential breaking change to IDbSet

The DbSet classes (generic and non-generic) inherit from a (generic or non-generic) IDbSet interface. IDbSet is intended only for creating test doubles, be these mocks or fakes. However, in EF6 DbSet has changed in four ways that if reflected in equivalent changes for IDbSet would be breaking changes:

FindAsync added
AddRange/RemoveRange added
Local return type changed to DbLocalView (this change may be reverted anyway)

The options discussed were:

Make the breaking change
- EF6 has no binary compat story to EF5 anyway because of the move out of the Framework
- This is the easiest for anyone using a mocking framework such as Moq which will automatically handle the new members
- Manually created test doubles will break and need to be updated
- Doing this now leaves us in the same state the next time we want to add something to DbSet at which time there will hopefully be a binary compat story
Make DbSet more mockable
- These means adding a protected constructor and making methods virtual
- Note that a type derived from DbSet that uses the protected constructor would create an object not be bound to any context and the methods would be no-ops. This makes it very like IDbSet from the perspective of creating test doubles.
- If we took this option we could potentially obsolete IDbSet
- It’s worth noting that no cases have been identified where this would be functionally different to using IDbSet for test doubles. However, there is strong feeling in the community that interfaces are preferred.
Introduce an abstract base class
- This is essentially the same as the previous option except that DbSet itself stays the same and an abstract base class is instead inserted underneath it
- This has the advantage that it provides a way to communicate what the base type is for (test doubles)
- However, it adds a class that doesn’t really need to be there and means that you have to use this base class in your context if you ever want to use test doubles
Use extension methods with delegation
- We have a pattern that we use for Include where the new members are added as extension methods which then delegate quickly into the real DbSet if the IDbSet is a real DbSet and otherwise use Reflection to call a method with the same signature on the test double
- This works okay, but the pattern is obscure and people would likely have to know that the extension methods work in this way to use it effectively. Also, even when it is known that the extension method works in this way it can still be a bit confusing to see how to use this with a mocking framework.
Create a new interface type (e.g. IDbSet2) that extends the original interface type
- This meets all the requirements but is an ugly pattern that adds a new interface type when, conceptually, it is not needed. This gets even worse if we ever have to do it again.

The decision was to make DbSet more mockable. However, we will not obsolete IDbSet because this would create work for those currently using IDbSet who don’t need to use the new members. We will add guidance to IDbSet indicating that using DbSet is the way to go for new code and, depending on feedback, we may choose to obsolete IDbSet in a future release.

Conversion to lightweight conventions

The configuration conventions used by EF are being converted to lightweight conventions are part of the the process to remove the “traditional” configuration conventions. As expected this has exposed some issues in the lightweight API for things that cannot be done or cannot be done cleanly.

Navigation property configuration

It is currently not possible to configure navigation properties using lightweight conventions. We considered creating some version of the relationship mapping fluent API for lightweight conventions, but this API is both very tied to generic types and the filtering they allow and also much more appropriate for configuring individual relationships rather than multiple relationships as is usually the case for conventions.

The proposed solution is to add a NavigationProperty method when using the Entities API that mirrors the Property method but has members suitable for navigation property configuration rather than scalar property configuration. We considered collapsing these into just one Property method but the intersection of members is very small. Also, if this API is reflected on the normal fluent API then it makes sense to separate the concepts both to retain the fluent type filtering and keep the two concepts conceptually separated.

Sub-questions:

Should we have a top-level NavigationProperties method that mirrors the top-level Properties method? We decided not to do this now for two reasons:
- We don’t have an actual scenario where we need it and while it is possible to think of some where it might be useful the only ones we could think of would not work because of the second reason:
- We have no way of knowing if the potential navigation property will remain a navigation property in the final model. This is because every reference between types is initially considered a navigation property. However, if at a later time one of the types is configured as a complex type or turned into a complex type by convention, then the potential navigation properties are no longer actual navigation properties.
Should Properties also include navigation properties? We decided to not do this now for both the same reasons that we are not doing NavigationProperties and also because it is consistent with other APIs that navigation properties be considered differently from scalar properties.
- We could choose to have an additional common API in the future, similar to what we have for the DbContext change tracker API.
Should we introduce a NavigationProperty API on the non-conventions fluent API?
- This will likely be needed for o/c mapping changes such as mapping to fields.
- We will not do this for EF6 because it isn’t needed for anything we are doing in this release, but we will likely introduce it in the future.

Entities returning complex types

There are currently a few issues with the Entities methods:

Entities currently returns only entity types, but we now need Entities to return types that have been configured as complex types.
Currently, some types returned by Entities may get later transformed into complex types, which can be confusing.
Entities shows up before Entity in Intelisense, which is annoying.

Given this we will rename this method to “Types”. Note that any configuration done on a type that can be done on either a complex type or an entity type should not change whether or not change the type from a complex type to an entity type. On the other hand, explicitly configuring the type as a complex/entity type in the convention should be possible and honored. Also, configurations that imply and entity type (such as key configuration or navigation property configuration) should influence the complex type convention in the normal way.

ModelNamespaceConvention

ModelNamespaceConvention is the only convention that cannot be converted to lightweight conventions. This is a convention used by DbContext to set the model namespace to the DbContext namespace. This makes the EDM look nicer for those cases where the EDM is exposed, such as OData. It has always been possible to remove this convention, but never possible to use it to change the namespace in some other way. We have also not seen any requests to be able to do this. (The model namespace is never exposed for the vast majority of EF users.)

Options are:

Add a property on DbModelBuilder and obsolete the convention. The problem with this is that it pollutes the model builder API for something that will hardly ever be used.
Leave as is. This doesn’t substantially change the consolidation work and so is probably okay.
Leave as is, but make the constructor public. This allows people to change the model namespace to something else if they want to.

We will leave as is but make the constructor public. Making the constructor public has very little value but also a very low risk change such that there doesn’t seem like a reason not to do it.

Lightweight conventions are wrapped as configuration conventions

This is the mechanism that allows a lightweight convention to be factored into a class and then added with the traditional convention API. The question is whether or not this should change given the move to only use lightweight conventions? The decision was to leave the design as is since it seems to work generally as people expect including when the conventions get run. It would be possible to call Entities again inside the outer Entities call, and this would not work as expected, but this is not a natural pattern and doesn’t seem like something to be too concerned about.

Updated Wiki: Design Meeting Notes - May 16, 2013

ajcvickers — Thu, 16 May 2013 23:57:34 GMT

New Comment on "specs"

uyhung — Wed, 15 May 2013 09:12:00 GMT

One of the most important features that we expect EF support is batch processing for INSERT, UPDATE, DELETE. When will we support it ? Or we will never support ?

Updated Wiki: specs

ajcvickers — Tue, 14 May 2013 16:36:52 GMT

Entity Framework 6

As we work on EF6 we will be creating feature specifications, walkthroughs and other documentation.

Runtime

Here is a list of the new features in the EF6 runtime and the documentation we have created for them.

Async Query and Save adds support for the task-based asynchronous patterns that were introduced in .NET 4.5. We've created a walkthrough and a feature specification for this feature.
Custom Code First Conventions allow write your own conventions to help avoid repetitive configuration. We provide a simple API for lightweight conventions as well as some more complex building blocks to allow you to author more complicated conventions. We’ve created a walkthough and a feature specification for this feature.
Code First Mapping to Insert/Update/Delete Stored Procedures is now supported. We’ve created a feature specification for this feature.
Connection Resiliency enables automatic recovery from transient connection failures. The feature specification shows how to enable this feature and how to create your own retry policies.
Dependency Resolution introduces support for the Service Locator pattern and we've factored out some pieces of functionality that can be replaced with custom implementations. We’ve created a feature specification and a list of services that can be injected.
Code-Based Configuration gives you the option of performing configuration – that was traditionally performed in a config file – in code. We've created an overview with some examples and a feature specification.
Configurable Migrations History Table allows you to customize the definition of the migrations history table. This is particularly useful for database providers that require the appropriate data types etc. to be specified for the Migrations History table to work correctly. We’ve created a feature specification for this feature.
Multiple Contexts per Database removes the previous limitation of one Code First model per database when using Migrations or when Code First automatically created the database for you. We’ve created a feature specification for this feature.
DbModelBuilder.HasDefaultSchema is a new Code First API that allows the default database schema for a Code First model to be configured in one place. Previously the Code First default schema was hard-coded to "dbo" and the only way to configure the schema to which a table belonged was via the ToTable API.
Enums, Spatial and Better Performance on .NET 4.0 - By moving the core components that used to be in the .NET Framework into the EF NuGet package we are now able to offer enum support, spatial data types and the performance improvements from EF5 on .NET 4.0.
DbContext can now be created with a DbConnection that is already opened which enables scenarios where it would be helpful if the connection could be open when creating the context (such as sharing a connection between components where you can not guarantee the state of the connection).
Default transaction isolation level is changed to READ_COMMITTED_SNAPSHOT for databases created using Code First, potentially allowing for more scalability and fewer deadlocks.
DbContext.Database.UseTransaction and DbContext.Database.BeginTransaction are new APIs that enable scenarios where you need to manage your own transactions.
Improved performance of Enumerable.Contains in LINQ queries.
Significantly improved warm up time (view generation) – especially for large models – as the result of a contribution from AlirezaHaghshenas.
DbModelBuilder.Configurations.AddFromAssembly method was contributed by UnaiZorrilla. If you are using configuration classes with the Code First Fluent API, this method allows you to easily add all configuration classes defined in an assembly.
Custom Migrations Operations were enabled by a contribution from iceclow and this blog post provides an example of using this new feature.
Pluggable Pluralization & Singularization Service was contributed by UnaiZorrilla.
Improved Transaction Support updates the Entity Framework to provide support for a transaction external to the framework as well as improved ways of creating a transaction within the Framework. See this feature specification for details.
Improved POCO support. Entity and complex types can now be nested inside classes and can have custom implementations of Equals or GetHashCode.
Interception/SQL logging. Low-level building blocks for interception of EF operations with simple SQL logging built on top.

Tooling

Here are the changes and features we are planning for the EF6 tooling.

The Basics covers things that aren’t classified as features but are required to provide a good tooling experience. Topics include branding, installation, supported VS versions, supported EF versions, etc.
Tooling Consolidation will combine the EF Power Tools and the EF Designer to provide a single set of tooling with a single wizard for creating new models. We’ve created a feature specification for this feature.

Entity Framework 5

The EF5 release was largely completed prior to moving to CodePlex, these documents only include the final set of changes made in EF5.

Backlog

These documents are for features that have not yet been assigned a release.

Updated Wiki: Interception

ajcvickers — Tue, 14 May 2013 16:32:02 GMT

Interception

Goals

The high-level goal for the interception feature is to allow external code to observe and potentially intercept EF operations. The specific goal for EF6 is to allow generated SQL to be logged without using a wrapping provider. A sub-goal to this is to provide a simple way for applications to log generated SQL.

Interception interfaces

The interception code is built around the concept of interception interfaces. These interfaces inherit from IDbInterceptor and define methods that are called when EF performs some action. The intent is to have one interface per type of object being intercepted. For example, the IDbCommandInterceptor interface defines methods that are called before EF makes a call to ExecuteNonQuery, ExecuteScalar, ExecuteReader, and related methods. Likewise, the interface defines methods that are called when each of these operations completes.

Currently public interception interfaces exist for DbCommand and DbCommandTree.

The interception context

Looking at the methods defined on any of the interceptor interfaces it is apparent that every call is given an object of type DbInterceptionContext or some type derived from this such as DbCommandInterceptionContext<>. This object contains contextual information about the action that EF is taking. For example, if the action is being taken on behalf of a DbContext, then the DbContext is included in the DbInterceptionContext. Similarly, for commands that are being executed asynchronously, the IsAsync flag is set on DbCommandInterceptionContext.

Collecting this information together into an object keeps the interface methods relatively simple and allows new contextual information to be added in the future with it being a breaking change on the interface.

Caveat

It’s worth noting that the interception context is a best effort to provide contextual information. However, in some corner cases some information that you would expect to be there may not be there. This is because EF has code paths that cannot easily be changed and do not include information that might be expected. For example, when EF makes a call into a provider, the provider has no knowledge of the DbContext being used. If that provider, outside of EF, decides to call ExecuteNonQuery, then two things might happen:

First the provider may just make the call directly, avoiding EF interception completely. (This is a consequence of having interception at the EF level rather than lower in the stack. It would be great if interception were lower in the stack, but this is unfortunately outside of the control of the EF team.)
If the provider is aware of EF interception then it can dispatch the ExecuteNonQuery call through EF interceptors. This means that any registered interceptor will be notified and can act appropriately. This is what the SQL Server and SQL Server Compact providers do. However, even when a provider does this it is likely that the DbContext being used will not be included in the interception context because the provider has no knowledge of it, and a change to allow this would break the well-defined provider APIs.

Luckily this kind of situation is rare and will likely not be an issue for most applications.

Result handling

The generic DbCommandInterceptionContext<> class contains a property called “Result”. This property is set to null/zero for calls to the …Executing methods and is then set to the result of the operation for the calls to the …Executed methods. This means, that in simple scenarios such as logging the result can be be observed and logged.

Changing Result before execution

If an interceptor sets the Result property before the command has executed (in one of the …Executing methods) then EF will not attempt to actually executed the command. Instead the result set will be used directly by EF.

An example of how this might be used is the command batching that has traditionally been done with a wrapping provider. The interceptor would store the command for later execution as a batch but would “pretend” to EF that the command had executed as normal. Note that it requires more than this to implement batching, but this is an example of how changing the interception result might be used.

Changing Result after execution

If an interceptor sets the Result property after the command has executed (in one of the …Executed methods) then EF will use the changed result instead of the result that was actually returned from the operation.

Registering interceptors

Once a class that implements one or more of the interception interfaces has been created it can be registered with EF using the Interception class. For example:

Interception.AddInterceptor(new NLogCommandInterceptor());

Dispatching

In addition to methods for the registration of interceptors, the Interception class also has a Dispatch method. This method allows code that is not part of EF to dispatch notifications to interceptors on behalf of EF. This is the mechanism mentioned above that allows providers to let interceptors know that that a command is being executed outside of the control of EF. It would be rare for an application developer to ever need to use the Dispatch API, but in sure rare cases the calls would look like this:

Interception.Dispatch.Command.AsyncNonQuery(
    myCommand, new DbCommandInterceptionContext<int>());

This line of code will do the following:

Make sure that IsAsync is set on the interception context
Call NonQueryExecuting on all registered IDbCommandInterceptors
Call ExecuteNonQueryAsync on the given command, unless one of the NonQueryExecuting methods set the Result property as described above
Setup continuations on the async task such that NonQueryExecuted is called on all registered IDbCommandInterceptors
Make sure that the result task contains the correct value, which may have been changed by one of the interceptors

Context Log property

The DbContext.Database.Log property can be set to a delegate for any method that takes a string. In particular, it can be used with any TextWriter by setting it to the “Write” method of that TextWriter. All SQL generated by the current context will be logged to that writer.

When the Log property is set all of the following will be logged:

SQL for all different kinds of commands. For example:
- Queries, including normal LINQ queries, eSQL queries, and raw queries from methods such as SqlQuery
- Inserts, updates, and deletes generated as part of SaveChanges
- Relationship loading queries such as those generated by lazy loading
Parameters
Whether or not the command is being executed asynchronously
A timestamp indicating when the command started executing
Whether or not the command completed successfully, failed by throwing an exception, or, for async, was canceled
Some indication of the result value
The approximate amount of time it took to execute the command

DbCommandLogger

Under the covers the Database.Log property makes use of a DbCommandLogger object. This object effectively binds a IDbCommandInterceptor implementation to a delegate that accepts strings and a DbContext. This means that interception methods on DbCommandLogger are called before and after the execution of commands by EF. These DbCommandLogger methods gather and format log output and send it to the delegate.

Changing what is logged and how it is formatted can be achieved by creating a new class that derives from DbCommandLogger and then overriding methods as appropriate. The most common methods to override are:

LogCommand – Override this to change how commands are logged before they are executed. By default LogCommand calls LogParameter for each parameter; you may choose to do the same in your override or handle parameters differently instead.
LogResult – Override this to change how the outcome from executing a command is logged.
LogParameter – Override this to change the formatting and content of parameter logging.

Once a new DbCommandLogger class has been created it needs to be registered with EF. This is done using code-based configuration. In a nutshell this means creating a new class that derives from DbConfiguration in the same assembly as your DbContext class and then calling SetCommandLogger in the constructor of this new class.

Updated Wiki: Interception

ajcvickers — Mon, 13 May 2013 23:02:52 GMT

Updated Wiki: Design Meeting Notes

ajcvickers — Thu, 09 May 2013 23:29:57 GMT

Entity Framework Design Meeting Notes

May 9, 2013

Interception building blocks
DbContext.Database.Log

April 11, 2013

Default providers
- The default connection factory
- Default provider configuration
- Additional config file elements
- DbProviderServices methods
Model-based conventions exploratory testing

April 4, 2013

Revisit: Using ExecuteSqlCommand without a transaction
Revisit: Extension method class naming
New transient error codes

April 2, 2013

API Review: Multiple Contexts per Database
API Review: Configurable Migrations History Table

March 28, 2013

Rename of DbExtensions to IQueryableExtensions
Pattern for customizing migrations history table
Turning off automatic transaction creation
Buffering in EntityClient

March 21, 2013

Missing property handling in lightweight conventions
Code First stored procedure mapping

March 19, 2013

Connection Resiliency Review

March 18, 2013

Async Query & Save API Review

March 14, 2013

File/code-based configuration precedence

March 13, 2013

Custom Code First Conventions

March 7, 2013

Custom migration operations usability
WrapService naming
Database initializers and shared databases

February 28, 2013

Models with nested types in Code First
Configuration of connection resiliency execution strategy
Behavior of disposed DbContextTransaction

February 20, 2013

Mapping to fields
Removal of unused resources

February 14, 2013

Branching for EF releases
Pull request: extending Migrations
Code First: modification function mapping API (mapping to stored procs)

February 7, 2013

DbContext and transactions (continued)
Pull request: extending Migrations
Issues with SQL Server spatial types

January 31, 2013

DbContext and transactions
Code First: modification function mapping (mapping to stored procs)

January 24, 2013

Buffering data reader perf
Provider-agnostic testing
Porting old SQL tests

January 17, 2013

Metadata API surface
Pluralization service exploratory testing feedback
Metadata unification
Porting existing SQL tests
How should pluralizers be made available?

January 10, 2013

Clustered/non-clustered unique identifier primary keys and SQL Azure

December 13, 2012

Lightweight conventions
Clustered/non-clustered unique identifier primary keys
Potential contribution for pluralization service

December 6, 2012

Additional ObjectContext and EntityConnection constructors
Default schema changes during initialization
Making EF queries buffer by default
SQL Azure connection resiliency
WET, DAMP, or DRY tests

November 29, 2012

Handling pull requests
Making READ_COMMITTED_SNAPSHOT the default
Database First WinForms data binding

November 20, 2012

Automatic EntityTypeConfiguration discovery

November 15, 2012

Lightweight conventions
View generation API
Removal of Code Contracts

November 8, 2012

Lightweight conventions
Connection resiliency to transient failures

October 25, 2012

Change default mapping for DateTime
Lightweight conventions
DbConfiguration exploratory testing
Code Contracts discussion

October 11, 2012

Lightweight conventions

October 4, 2012

Global spatial provider
Set-based configuration

September 27, 2012

Dependency resolver scoping
Sugar methods for services
Simplified API for common conventions

September 20, 2012

By-convention parameter binding SqlQuery overload
SqlCE relative path connection string UX issues with Migrations
Pluggable Conventions
Polish the conventions API
Breaking change

August 23, 2012

Make ObjectContext implement IObjectContextAdapter
Migrations multi-tenancy
Designer versioning
Async protection

August 9, 2012

Getting schema Information from providers
Using IDbDependencyResolver with existing IoC containers

August 2, 2012

CUD Batching
Bulk operations

July 26, 2012

Async
One-pagers
Initializer proposal

July 12, 2012

Model key caching
Migrations history table schema changes
Async immediate LINQ operators

July 5, 2012

Refactoring and unit tests

June 28, 2012

Code contracts

June 21, 2012

Code-based configuration

June 14, 2012

Making database connections in the test suite more configurable

June 7, 2012

Naming convention for static readonly and const fields
How will we handle breaking changes in EF6?
High-level ideas for using dependency injection with EF and specifics for the provider

May 31, 2012

Making EF code more testable
Code duplication in Async
Supporting MVC scaffolding

Updated Wiki: Design Meeting Notes - May 9, 2013

ajcvickers — Thu, 09 May 2013 23:24:46 GMT

Design Meeting Notes - May 9, 2013

Interception building blocks

An overview of the interception feature will be posted to the feature specifications page. The notes below do not cover the entire feature but rather the points discussed in the design meeting where a change was considered.

Interfaces and base classes

Currently the plan is to have one interface per type that can be intercepted. So, for example, there is currently an IDbCommandInterceptor and and IDbCommandTreeInterceptor, and in the future there might be an IDbConnectionInterceptor. There is also currently a single base type that implements all the public interception interfaces.

Question: would it be simpler to understand and use if there were a single interface or base type and no interfaces?

The current separation was done for several reasons:

The design minimizes perf impact for code that needs to intercept for one type but not another. This is because if no interceptor is registered for a given type then EF doesn’t need to make any calls for that type. With a single type EF has no way of knowing whether or not a call into the interceptor is required for a given type and so would always call.
- This raises the question of whether or not we should even provide a base class that implements all the interfaces
This helps prevent breaking changes compared to a single interface that we would not be able to add to without it being a breaking change.
- A single base type would not have this issue, but then no interceptor would be able to have any other base type
The interfaces factor related interceptions together into manageable groups

Decisions:

We will will continue to have interfaces organized like this
We will remove the single base class since it promotes a bad pattern and instead of base classes for any interception interface with many methods

Other interceptors for EF6

Given where we are in the development cycle for EF6 should we consider adding any additional interceptors? In particular, a LINQ expression tree interceptor? Decision: we will do this post EF6.

Related to this, are there other things that it is worth intercepting on DbCommand?

Interception of properties doesn’t seem valuable
For other methods:
- Cancel is never called by EF
- CreateParameter is only called when creating parameters for a raw SQL query, and parameters can be examined and manipulated for execution anyway
- Prepare is never called by EF
- Dispose for a command doesn’t seem to be valuable to intercept

Decision: we will not add anything here

Filtering design

Currently all interceptors are registered globally. This means that interception for a specific DbContext or ObjectContext requires that the interceptor filter for the context. If many contexts in a single app domain are all doing this it might have a perf impact. However this is speculative and has not been demonstrated.

A solution to this could be to include the DbContext and/or ObjectContext in the interceptor registration.

Decision: we will not do this at this time because:

If it turns out that this really is an issue then we can make this change in the future without it being a breaking change
A more appropriate pattern for an application that needs to intercept for multiple contexts would be to create a single interceptor to do this
- This is also more appropriate because it allows efficient filtering by context type, which is often more useful than context instance in these situations
If this is never needed, then adding anyway adds to design and API complexity and concept count

Collapse everything into the interception context

We discussed the idea of collapsing all the methods together on IDbCommandInterceptor and putting all information (DbCommand, result, method being intercepted, etc.) into the context. However, the general feeling was that keeping the object being intercepted (DbCommand in this case) as first class was worthwhile, and that collapsing all the methods would make the interface harder to understand and could result in a lot of switch-like code.

Result handling and operation overrides

Currently the “Executed” interception methods on IDbCommandInterceptor receive a parameter that is the result of executing the operation. These methods then return a value which should normally be this result. However, the interceptor can change the result by returning a different value. This can be useful in situations where the provider returns a result such as 0 rows affected but the interceptor knows that really the correct thing happened and wants to return 1 to EF so that EF does not throw a concurrency exception.

The problem with this pattern is that when implementing the interface it is not immediately obvious what the return value from the method is for or what should be returned.

Related to this is that it would be useful to allow the interceptor to tell EF not to actually perform the operation. For example, consider a wrapping provider that is attempting to batch. One approach for this is to collect all the commands but then hold off on executing them immediately. For this to be possible with interception the interceptor needs to be able to tell EF not to execute the commands. Note that this is similar but different from cancelation since EF should continue as though the operation was executed using whatever result the interceptor provides.

Two possible solutions to these problems will be investigated:

Allow the interception context to be mutated such that preventing command execution and result modification can be done by changing the interception context
Provide another, mutable object that allows result modification and execution cancelation

We also considered using ref parameters, but the general feeling was that we should avoid doing this if possible.

Related to this is that, where possible, we should use a more specific name for the result, such as “rowsAffected”.

DbContext.Database.Log

Built on top of the interception building blocks is a LINQ to SQL-like “Log” property that can be set to a TextWriter. For example, code like this:

using (var context = new BlogContext())
{
    context.Database.Log = Console.Out;

    var blog = context.Blogs.First(b => b.Title == "One Unicorn");

    blog.Posts.First().Title = "Green Eggs and Ham";

    blog.Posts.Add(new Post { Title = "I do not like them!"});

    context.SaveChangesAsync().Wait();
}

Will output something like this to the console:

SELECT TOP (1)
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title]
FROM [dbo].[Blogs] AS [Extent1]
WHERE (N'One Unicorn' = [Extent1].[Title]) AND ([Extent1].[Title] IS NOT NULL)
-- Completed with result: SqlDataReader

SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title],
[Extent1].[BlogId] AS [BlogId]
FROM [dbo].[Posts] AS [Extent1]
WHERE [Extent1].[BlogId] = @EntityKeyValue1
-- EntityKeyValue1: Input Nullable Int32 (Size = 0; Precision = 0; Scale = 0) [1]
-- Completed with result: SqlDataReader

update [dbo].[Posts]
set [Title] = @0
where ([Id] = @1)
-- @0: Input Nullable String (Size = -1; Precision = 0; Scale = 0) [Green Eggs and Ham]
-- @1: Input Nullable Int32 (Size = 0; Precision = 0; Scale = 0) [1]
-- Executing asynchronously
-- Completed with result: 1

insert [dbo].[Posts]([Title], [BlogId])
values (@0, @1)
select [Id]
from [dbo].[Posts]
where @@rowcount > 0 and [Id] = scope_identity()
-- @0: Input Nullable String (Size = -1; Precision = 0; Scale = 0) [I do not like them!]
-- @1: Input Nullable Int32 (Size = 0; Precision = 0; Scale = 0) [1]
-- Executing asynchronously
-- Completed with result: SqlDataReader

TextWriter or something else?

Should the property be a TextWriter, an event, or delegate? The advantage of TextWriter is that it is really simple to use and is a pattern that was introduced and well-liked in LINQ to SQL. It is worth keeping in mind that this is intended to be a really simple way to Log—full power is provided by the interception building blocks. An event could be used, but multi-cast is not required and, for this simple case, neither are event args, sender, etc. Changing the TextWriter to a delegate would not add significantly to how hard it is to use especially given that use of lambdas is now a relatively well understood pattern.

Decision: we will investigate using a delegate instead.

Output format

The default output format (which is easy to change) was discussed with the following conclusions:

Parameters will not be inlined by default, but we will consider creating a DbInliningCommandLogger which can be switched in for those who want executable SQL
- The reason for this is that parameter information is useful and this is lost using a simple inlining approach
- A simple inlining approach also means that what is logged is not actually what is sent to the database
- Adding code to set and create parameters as comments would be nice, but it would be both quite verbose and require provider changes to do in a provider-agnostic way
A timestamp will be included before the command is executed and a time-elapsed value will be included after the command has executed
The parameter value will be moved to the start of the parameter output
Parameter facets (precision, scale, etc.) will only be included if they have non-default values

Updated Wiki: Design Meeting Notes - May 9, 2013

ajcvickers — Thu, 09 May 2013 20:10:03 GMT

New Comment on "Connection Resiliency Spec"

AndriySvyryd — Wed, 08 May 2013 22:32:26 GMT

@GuardianAngel Outer transactions aren't supported because when an operation that is part of an existing transaction fails then the transaction is rolled back, but the retry strategy isn't aware of what other operations were executed in that transaction previously so it can't retry them. SupportsExistingTransactions flag is for strategies that don't ever retry the execution. The execution strategy does support transactions started inside the retryable action and actually in most cases we start a new transaction if one didn't exist. If in your scenario you need to execute several operations in a single transaction then instead of globally enabling SqlAzureExecutionStrategy you can create a new instance of it and call Execute passing in the block that starts the transaction and executes the operations. Also if this is the case please share your scenario as we are looking for ways to make this experience better.

Updated Wiki: Code-based Configuration

RoMiller — Mon, 06 May 2013 20:35:06 GMT

Code-based Configuration

Background

In EF 4.1 most configuration was done through code. In EF 4.3 we added the EntityFramework configuration section to allow configuration via config file.

Both code-based configuration and file-based configuration are useful. Code-based configuration can make use of IDE and compiler services (strong typing, Intellisense, etc.) and is flexible especially when coupled with dependency injection. File-based configuration can allow the same code to run in different environments without re-compiling.

The main problem with code-based configuration is making sure that the configuration is available to design-time tooling that does not run the application. The tooling must be able to find and execute (or otherwise interpret) the code. This is not possible if the configuration is performed by some arbitrary call made at some point during app startup.

Goals

If I don’t know about or care about using code-based configuration, then everything still works
If I do want to use code-based configuration then it should be simple to do for the main developer scenarios
If I use it in this simple way, then tooling will also be able to find and use my code-based configuration
Whatever we add now should also form the basis for adding new configuration going forward
Less common scenarios (no context, multiple contexts, using Code First building blocks, etc.) may require more work but should still be easy with code-based configuration

The DbConfiguration class

EF provides a DbConfiguration base class. To use code-based configuration a developer creates a class derived from DbConfiguration and places it in the same assembly as their DbContext class. Configuration settings are made in the constructor of this class. For example:

public class MyConfiguration : DbConfiguration
{
    public MyConfiguration()
    {
        SetDefaultConnectionFactory(new LocalDbConnectionFactory("v11.0"));
        AddDbProviderServices("My.New.Provider", new MyProviderServices());
    }
}

This class should be placed in the same assembly as the context class so that EF is able to discover it. However, note that this is configuration for the app-domain, not just for the context. The reason for this is that there are many things that can be done with EF that don’t require a context—for example, building a Code First model with DbModelBuilder. This configuration will still be used for such things even though no context is being used.

Design-time discoverability

As stated above, one of the goals for DbConfiguration is to allow design-time discoverability of configuration for a context. Design-time tools that know the context are also able to discover and create an instance of your derived DbConfiguration class because it is located in the same assembly.

Configuration methods (such as SetDefaultConnectionFactory and AddDbProviderServices) must be called from the constructor because this ensures that all configuration is set when the design-time tools create the DbConfiguration instance. The design-time tools have no way of finding or running other code to set configuration.

Relationship to dependency resolution

The post on EF dependency resolution describes the IDbDependencyResolver interface and how it used to set/change EF configuration. Methods like SetDefaultConnectionFactory or AddDbProviderServices actually work by adding new dependency resolvers to the chain. These methods are provided as a convenience so that you don’t have to create resolvers. However, if you want greater control over configuration then you can create your own resolvers, possibly making use of an IoC container, and use the AddDependencyResolver method instead.

Using AddDependencyResolver also allows mutation of configuration while the app is running (by changing what the resolver returns) but doing this can defeat design-time discoverability of the configuration so it should be done with care.

Config file precedence

Some of the options you can set using code-based configuration can also be set in the application’s config file. Anything set in the config file always takes precedence over code-based configurations. This allows the config file to be used to change the way an application is configured without requiring that the application be re-compiled.

Moving DbConfiguration

Two options exist to handle cases where it is not possible to place the DbConfiguration class in the same assembly as the context:

You can use the config file to specify the DbConfiguration instance to use. To do this, set the codeConfigurationType attribute of the entityFramework section. For example:
```
<entityFramework codeConfigurationType="MyNamespace.MyDbConfiguration, MyAssembly">
    ...Your EF config...
</entityFramework>
```
You can place a DbConfigurationTypeAttribute on your context class. For example:
```
[DbConfigurationType(typeof(MyDbConfiguration))]
public class MyContextContext : DbContext
{
}
```
Note: We do not support having multiple configuration classes used in the same AppDomain. If you use this attribute to set different configuration classes for two contexts an exception will be thrown.

Setting DbConfiguration explicitly

There are some situations where configuration may be needed before any DbContext type has been used—for example, when using Code First to build a model without a context. There are two ways to allow EF find the configuration in such cases:

Set the DbConfiguration type in the config file, as describe above
Call DbConfiguration.SetConfiguration during application startup

When calling DbConfiguration.SetConfiguration if a context is later used then it must still be able to find the same configuration class. This helps prevent unexpected behavior in design-time tools.

Updated Wiki: EF Configuration and Extensibility

RoMiller — Mon, 06 May 2013 20:20:41 GMT

EF Dependency Resolution

Introduction

EF has historically taken a rather ad-hoc approach to runtime configuration and extensibility. The changes for EF6 described here and in the post covering code-based configuration 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.

This spec describes low level building blocks

The components described in this spec are low level building blocks that will only be used in advanced scenarios. Developers wishing to make simple configuration changes from code should use the DbConfiguration class described in the code-based configuration spec. DbConfiguration provides a simple façade over the components described here.

Goals

The changes described in these specs address the following 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.

Service Locator pattern

The most fundamental underlying building block here is the use of the Service Locator pattern as represented by the IDbDependencyResolver interface:

public interface IDbDependencyResolver
{
    object GetService(Type type, object key);
}

At the most basic level, when EF needs an implementation of some interface or base class it will call GetService passing in the interface or base class type and will get back the implementation to use.

IDbDependencyResolver is similar to the IDependencyResolver interfaces of ASP.NET MVC and Web API.

The resolver chain

Internally, EF maintains a list of classes that implement this interface and uses the Chain-of-Responsibility pattern to resolve services it needs from this chain. That is, it calls GetService on the first IDbDependencyResolver in the list. If this implementation returns null, then it calls GetService on the next. This continues until either a non-null object is returned or the last resolver in the chain is reached. This last resolver is always the “root” resolver which will resolve any service needed by EF with a default implementation if none of the other resolvers in the chain resolve the service first.

In practical terms this means that if you use EF6 out of the box without doing anything then all services needed by EF are resolved by the root resolver to the EF defaults. If you want to change one or more of the defaults then you can add one or more new IDependencyResolver implementations to the chain. EF will then resolve the service using the resolver(s) you have added and will no longer use the defaults provided by the root resolver. For any services that your resolver(s) do not handle, the defaults provided by the root resolver will still be used.

For example, to change the default connection factory you can write a DbConfiguration class like so:

public class MyAppConfiguration : DbConfiguration
{
    public MyAppConfiguration()
    {
        AddDependencyResolver(new MyDependencyResolver());
    }
}

public class MyDependencyResolver : IDbDependencyResolver
{
    public object GetService(Type type, object key)
    {
        if(type == typeof(IDbConnectionFactory))
        {
            return new MyConnectionFactory();
        }

        return null;
    }
}

More details about DbConfiguration can be found in the post on code-based configuration (including information about performing configuration without having to worry about resolvers).

We also provide a SingletonDependencyResolver implementation of IDbDependencyResolver that returns the given object when GetService is called for the provided generic type and otherwise returns null. This makes it easy to override a specific dependency without having to write your own resolver:

public class MyAppConfiguration : DbConfiguration
{
    public MyAppConfiguration()
    {
        AddDependencyResolver(new SingletonDependencyResolver<IDbConnectionFactory><idbconnectionfactory>(new MyConnectionFactory()));
    }
}

What is the key?

This key argument is optionally used to provide information to the resolver about the requested service. For example, the provider invariant name string is passed as a key when when GetService is used to request an EF provider. A GetService implementation must then return the provider for the given invariant name.

The type and semantics of the key object, if any, is documented for each service that may be requested.

Isn’t Service Locator an anti-pattern?

Some people consider Service Locator to be an anti-pattern. This is for two main reasons:

It can lead to runtime errors if the locator does not know about and hence does not resolve a service, and it is often hard find out which services a locator must resolve.
No context is provided for the code attempting to resolve the service.

The first issue is addressed in the EF design through the resolver chain and the associated root resolver which is designed to resolve any dependencies not handled by other resolvers. This means that so long as the EF team updates the root resolver whenever a new service is added then it doesn’t matter that other resolver implementations don’t know about or handle the new service. Put another way, when you implement IDbDependencyResolver you don’t have to worry about resolving everything, you just resolve the services you are interested in.

The second issue is addressed in two ways. First, the key object provides context about the service being resolved. (The word “context” is used here in its general sense; it does not necessary refer to a DbContext/ObjectContext.) Also, in the design for scoping (see below) the key provides context information about the scope of the resolver being created.

How do I know what services can resolved?

The public services that can be resolved by an IDbDependencyResolver are documented on MSDN.

Generic extension methods

Only one GetService method is defined on IDbDependencyResolver to make it easy to implement this interface without lots of duplicate code. However, the most common way of calling the method is to use one of the extension methods:

public static T GetService<T>(this IDbDependencyResolver resolver, object key)
public static T GetService<T>(this IDbDependencyResolver resolver)
public static object GetService(this IDbDependencyResolver resolver, Type type)

For example, this:

var provider = resolver.GetService<DbProviderServices>("System.Data.SqlClient");

Is equivalent to this:

var provider = (DbProviderServices)resolver.GetService(typeof(DbProviderServices), "System.Data.SqlClient");

What about scopes?

Imagine a situation where a DbContext instance depends on a service object that must only live while the context exists and must be disposed when the context is disposed. We currently don’t have an services like this, but it is conceivable that we will in the future. We have therefore designed and prototyped a way to handle this and it is described in the EF design meeting notes for September 27, 2012.

Extensibility and open source contributions

Let’s say you want to add to or change EF behavior in some way. With the open source model you could submit a pull request, and in a lot of cases we are likely to accept it. However, there may be cases where the change is not appropriate for the core EF code for a number of reasons:

It might break existing applications
It might be an uncommon scenario that is useful to you but not the majority
Your implementation might work for you but not be general or robust enough to become a supported part of the product

In such situations you may still be able to make the change by creating an interface that is resolved using the mechanisms described above. We are very likely to accept such a changes since it is generally useful to increase the extensibility of the code in this way. With such a change in EF you will then be able to add the functionality you need without further changes to the EF code. If you choose you can still make your functionality available to others so that they can benefit from it.

Related information

The main entry point for EF dependency resolution is the DbConfiguration class which is described in a separate post on code-based configuration. We intend to also publish a post describing how to use IDbDependencyResolver with an off-the-shelf IoC container.

Updated Wiki: EF Configuration and Extensibility

ajcvickers — Wed, 01 May 2013 22:58:00 GMT

EF Dependency Resolution

Introduction

Goals

The changes described in these posts address the following 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.

Service Locator pattern

The most fundamental underlying building block here is the use of the Service Locator pattern as represented by the IDbDependencyResolver interface:

public interface IDbDependencyResolver
{
    object GetService(Type type, object key);
}

IDbDependencyResolver is similar to the IDependencyResolver interfaces of ASP.NET MVC and Web API.

The resolver chain

In practical terms this means that if you use EF6 out of the box without doing anything then all services needed by EF are resolved by the root resolver to the EF defaults. If you want to change one or more of the defaults then you can add one or more new IDependencyResolver implementations to the chain. EF will then resolve the service using the resolver(s) you have added and will no longer use the defaults provided by the root resolver. For any services that your resolver(s) do not handle the defaults provided by the root resolver will still be used.

For example, to change the default connection factory you can write a DbConfiguration class like so:

public class MyAppConfiguration : DbConfiguration
{
    public MyAppConfiguration()
    {
        AddDependencyResolver(new SingletonDependencyResolver<IDbConnectionFactory>(new MyConnectionFactory()));
    }
}

More details about DbConfiguration can be found in the post on code-based configuration. The SingletonDependencyResolver is an implementation of IDbDependencyResolver that returns the given object when GetService is called for the provided generic type and otherwise returns null. An example of a simple implementation for dependencies without keys (see below) is:

public class SingletonDependencyResolver<T> : IDbDependencyResolver
{
    private readonly T _singletonInstance;

    public SingletonDependencyResolver(T singletonInstance)
    {
        _singletonInstance = singletonInstance;
    }

    public object GetService(Type type, object key)
    {
        return type == typeof(T) ? _singletonInstance : null;
    }
}

What is the key?

The type and semantics of the key object, if any, is documented for each service that may be requested.

Isn’t Service Locator an anti-pattern?

Some people consider Service Locator to be an anti-pattern. This is for two main reasons:

It can lead to runtime errors if the locator does not know about and hence does not resolve a service, and it is often hard find out which services a locator must resolve.
No context is provided for the code attempting to resolve the service.

The first issue is addressed for in the EF design through the resolver chain and the associated root resolver which is designed to resolve any dependencies not handled by other resolvers. This means that so long as the EF team updates the root resolver whenever a new service is added then it doesn’t matter that other resolver implementations don’t know about or handle the new service. Put another way, when you implement IDbDependencyResolver you don’t have to worry about resolving everything, you just resolve the services you are interested in.

How do I know what services can resolved?

The public services that can be resolved by an IDbDependencyResolver are documented on MSDN.

Generic extension methods

public static T GetService<T>(this IDbDependencyResolver resolver, object key)
public static T GetService<T>(this IDbDependencyResolver resolver)
public static object GetService(this IDbDependencyResolver resolver, Type type)

For example, this:

var provider = resolver.GetService<DbProviderServices>("System.Data.SqlClient");

Is equivalent to this:

var provider = (DbProviderServices)resolver.GetService(typeof(DbProviderServices), "System.Data.SqlClient");

What about scopes?

Extensibility and open source contributions

It might break existing applications
It might be an uncommon scenario that is useful to you but not the majority
Your implementation might work for you but not be general or robust enough to become a supported part of the product

Related information

Updated Wiki: Code-based Configuration

ajcvickers — Wed, 01 May 2013 22:40:00 GMT

Code-based Configuration

Background

In EF 4.1 most configuration was done through code. In EF 4.3 we added the EntityFramework configuration section to allow configuration via config file.

Goals

If I don’t know about or care about using code-based configuration, then everything still works
If I do want to use code-based configuration then it should be simple to do for the main developer scenarios
If I use it in this simple way, then tooling will also be able to find and use my code-based configuration
Whatever we add now should also form the basis for adding new configuration going forward
Less common scenarios (no context, multiple contexts, using Code First building blocks, etc.) may require more work but should still be easy with code-based configuration

The DbConfiguration class

public class MyConfiguration : DbConfiguration
{
    public MyConfiguration()
    {
        SetDefaultConnectionFactory(new LocalDbConnectionFactory("v11.0"));
        AddDbProviderServices("My.New.Provider", new MyProviderServices());
    }
}

This class should be placed in the same assembly as the context class so that EF is able to discover it. However, note that this is configuration for the app-domain, not just for the context. The reason for this is that there are many things that can be done with EF that don’t require a context—for example, building a Code First most with DbModelBuilder. This configuration will still be used for such things even though no context is being used.

Design-time discoverability

Relationship to dependency resolution

Config file precedence

Moving DbConfiguration

Two options exist to handle cases where it is not possible to place the DbConfiguration class in the same assembly as the context:

You can use the config file to specify the DbConfiguration instance to use. To do this, set the codeConfigurationType attribute of the entityFramework section. For example:
```
<entityFramework codeConfigurationType="MyNamespace.MyDbConfiguration, MyAssembly">
    ...Your EF config...
</entityFramework>
```

You can place a DbConfigurationTypeAttribute on your context class. For example:

[DbConfigurationType(typeof(MyDbConfiguration))]
public class MyContextContext : DbContext
{
}

Setting DbConfiguration explicitly

Set the DbConfiguration type in the config file, as describe above
Call DbConfiguration.SetConfiguration during application startup

When calling DbConfiguration.SetConfiguration if a context is later used then it must still be able to find the same configuration class. This helps prevent unexpected behavior in design-time tools.

entityframework Wiki Rss Feed

Updated Wiki: specs

Entity Framework 6

Runtime

Tooling

Other Documentation

Entity Framework 5

Backlog

New Comment on "Code First Insert/Update/Delete Stored Procedure Mapping"

New Comment on "Improved Transaction Support"

New Comment on "Roadmap"

New Comment on "Documentation"

Updated Wiki: Design Meeting Notes

Entity Framework Design Meeting Notes

Updated Wiki: Design Meeting Notes - May 16, 2013

Design Meeting Notes - May 16, 2013

Time format in DbCommandLogger

Potential breaking change to IDbSet

Conversion to lightweight conventions

Navigation property configuration

Entities returning complex types

ModelNamespaceConvention

Lightweight conventions are wrapped as configuration conventions

Updated Wiki: Design Meeting Notes - May 16, 2013

New Comment on "specs"

Updated Wiki: specs

Entity Framework 6

Runtime

Tooling

Other Documentation

Entity Framework 5

Backlog

Updated Wiki: Interception

Interception

Goals

Interception interfaces

The interception context

Caveat

Result handling

Changing Result before execution

Changing Result after execution

Registering interceptors

Dispatching

Context Log property

DbCommandLogger

Updated Wiki: Interception

Updated Wiki: Design Meeting Notes

Entity Framework Design Meeting Notes

Updated Wiki: Design Meeting Notes - May 9, 2013

Design Meeting Notes - May 9, 2013

Interception building blocks

Interfaces and base classes

Other interceptors for EF6

Filtering design

Collapse everything into the interception context

Result handling and operation overrides

DbContext.Database.Log

TextWriter or something else?

Output format

Updated Wiki: Design Meeting Notes - May 9, 2013

New Comment on "Connection Resiliency Spec"

Updated Wiki: Code-based Configuration

Code-based Configuration

Background

Goals

The DbConfiguration class