While Entity Framework has a rather ignominious reputation for breaking backwards compatibility, it pales in comparison to the total rewrite undertaken for Entity Framework core. In this article InfoQ looks at some of the major feature changes and their repercussions.

Delayed and Deprecated Features

To begin with we’ll look at EF 6 features that are not supported in EF Core 1.0 and are not part of the EF Core 1.1 roadmap.

Lazy Loading

Lazy loading has always been a contentious issue for Entity Framework and ORMs in general. Originally EF was not supposed to support lazy loading, as it can be easily misused and often leads to poor performance.

However, lazy loading is also very useful for rapid prototyping and utility applications where performance isn’t critical. So it was added in the second major version, EF 4. (Note: EF skipped over versions 2 and 3 in order to align with .NET Framework version numbers.)

To the cheers of some and the consternation of other, EF Core shipped without lazy loading. The current advice is to wait until EF Core 1.1, at which time they “may enable rolling your own lazy loading”. Based on the various debates on GitHub and elsewhere, it is unclear if they will ever support it directly.

GROUP BY Translation

This is a confusing one. Though supported by LINQ to SQL a decade ago, EF Core doesn’t have GROUP BY support on its roadmap. This means that if your query includes grouping operations, EF Core will omit the GROUP BY clause in its query generation.

The obvious result is that this will dramatically increase network bandwidth requirements as the all of the underlying data needs to be moved to the middle tier before aggregation. Deserializing the additional data will come with a cost, plus C# is likely to be less efficient than the database at performing the actual grouping operations. (Databases have the advantage of being able to use table statistics such as table size and distribution to determine the best algorithm to use.)

Stored Procedures

Another surprising move by Microsoft was the decision to not support stored procedures. While you can technically still access them using raw SQL, there are a lot of limitations with that:

• SQL queries can only be used to return entity types that are part of your model [This feature is planned for .NET Core 1.1].
• The SQL query must return data for all properties of the entity type.
• The column names in the result set must match the column names that properties are mapped to. Note this is different from EF6.x where property/column mapping was ignored for raw SQL queries and result set column names had to match the property names.
• The SQL query cannot contain related data. However, in many cases you can compose on top of the query using the Include operator to return related data (see Including related data).

In some cases you can mix raw SQL with LINQ expressions, such as adding a Where or OrderBy call to a table-valued function query.

Spatial Data Types

Spatial data types are an interesting case. When using straight ADO.NET, developers are expected to use spatial types that are shipped with SQL Server as a wrapper around a COM library (Microsoft.SqlServer.Types). As COM doesn’t mix well with .NET, especially in terms of library distribution and registration requirements, Entity Framework developed its own parallel set of spatial types (System.Data.Spatial). Both APIs are based on the Open Geospatial Consortium (OGC) Specification and thus are quite similar in terms of basic functionality.

Thus far we are mainly talking about SQL Server. With other database come other implementation of the spatial types, so it is understandable that Microsoft is taking their time in trying to unravel this one.

Seed Data

While database migrations are supported by EF Core, the ability to populate lookup tables with seed data is not.

Simple Command Interception

Command Interception is used extensively to work-around limitations in Entity Framework’s SQL generator. For example, if you wish to use a full text search index in EF you need to implement the IDbCommandInterceptor interface and override the ReaderExecuting/ScalarExecuting methods.

The technique is rather messy and heavily relies on knowing exactly what SQL EF will generate, but without out many of the database’s advanced features become inaccessible.

Tooling

As mentioned in previous articles, the graphical modeling tools that originally shipped with LINQ to SQL and Entity Framework will not be made available for EF Core.

Furthermore, there are no current plans to be able to update a model from the database. Model generation from the database will remain a one-time event for the foreseeable future.

EF Core 1.1 Features

EF Core 1.1 is expected to be released by Q1 of next year. In addition to bug fixes, several features are slated for the next version:

Improved Translation

This troubling title lacks details. It merely says that it will “enable more queries to successfully execute, with more logic being evaluated in the database (rather than in-memory).” Elsewhere it says that EF 6 supports “simple”, “moderate”, and “complex” queries. Moderate queries are being “stabilized” in EF Core and complex query support is in development.

Since there are few hints as to which scenarios are covered, developers need to be extra careful to examine the generated SQL and profile their database calls to ensure that EF is behaving properly.

Likewise, queries using navigation properties are considered to be in development.

Queries for non-model types

As mentioned above, EF Core 1.1 is expected to be able to materialize types that are not part of the model.

DbSet.Find

This EF 5 convenience method used to load records by their primary key(s) without needing to explicitly name them. It hooks into the context’s cache, thus avoiding unnecessary database calls. It can also find records that were attached to the context but not yet saved to the database (assuming you are not using identity/auto-number columns).

EntityEntry/ObjectStateEntry APIs

Additional EntityEntry and ObjectStateEntry features such as Reload, GetModifiedProperties, GetDatabaseValues are likewise being planned.

Explicit Loading

Not to be confused with “eager loading”, explicit loading allows you to load child collections into an entity after it has been materialized. Think of it as lazy loading with an extra step.

Connection Resiliency

This promising feature will automatically retry transactions that fail due to connectivity issues. “This is especially useful when connection to SQL Azure, where transient failures are common.”

EF Core vNext Features

While not expected to be completed in the EF Core 1.1 timeframe, there are other features in the works:

• Complex/value types are types that do not have a primary key and are used to represent a set of properties on an entity type.
• Simple type conversions such as string => xml.
• Visual Studio wizard for reverse engineering a model from an existing database.