Why Entity Framework 7?

Upgrade to EF7 

If you’re currently on EF6, you might jump to the conclusion that you should upgrade to EF7 as soon as it hits the streets, but should we move to EF7? for some folks the answer will be, “Maybe never.” That’s right. There are certain features and development approaches that are being deprecated. The most notable is support for EDMX-based development, which is sometimes referred to as “model first” or “designer based.” Going forward, EF7 and beyond will only support code-based modeling, also known as “code first,” but which also includes reverse engineering code first entities from an existing database.

So if you have heavy investment in EDMX-based models, then you might want to completely rule out upgrading beyond EF6. After all, EF6 is mature, feature-rich, stable and performant. Because of that, it’s not going away anytime soon, and the team is continuing to fix defects and add minor features. It also might take a while for providers other than SQL Server, such as Oracle, to release versions that are compatible with EF7.

EF7 Applications

  • ASP.NET 5: This will be a “cloud-friendly” version of ASP.NET that allows you to target a stripped down and NuGet deployable version of the CLR, called .NET CLR Core. EF7 was re-written from the ground up mainly to support this scenario. Besides, EF6 won’t support CoreCLR and you’ll have to use EF7 if you want to take advantage of the version of .NET that targets the cloud.
  • Apps that use EF with code-based modeling (aka Code First), where you don’t use features not yet supported by EF7 . The bonus here is that EF7 is deployed as a set of Portable Class Libraries that can run on .NET 4.5.1, Windows 8.1 and Windows Phone 8.1 (and by extension on iOS and Android via Xamarin). There is also an In-Memory provider that is useful for testing scenarios.
  • You want to target non-relational data stores, such as Azure Table Storage or Redis, and you’re willing to wait for those providers to be written. In order to focus on rounding out the basic feature set and supporting ASP.NET 5, the EF team froze their work on non-relational providers. They will eventually come along, but you may need to wait a little while.
  • You want to target a local SQLite database on a mobile device and you’re willing to wait some more. Just like non-relational stores, development on the SQLite provider is being postponed until after the initial release and inclusion of basic features.

Beyond the support for ASP.NET 5, non-relational stores, and mobile platforms, most of what’s cool about EF7 is under the covers. It’s being written in the same modular fashion that makes ASP.NET 5 a compelling story. The idea behind it is to cut loose from the bonds of its legacy to provide a product where you can pick and choose just the components you need and can more easily insert custom extensions and configurations into the pipeline. This is what makes it cloud-friendly, because it reduces the application footprint in an environment where memory and processing resources are pay-as-you-go. And just like ASP.NET 5, EF7 has been designed so that dependency injection and testability are first-class citizens.

Starting from scratch has enabled the EF team to add features which were difficult to plug in while tethered to the old code base. These include batch updates (sending multiple statements to the database in a single round trip) and the ability to define unique constraints on entities besides the primary key. EF7 will also allow parts of queries to be executed locally and for providers to handle queries which produce multiple result sets.

Entity Framework 7 (EF7)

EF7 is more powerful and has significant changes over Entity Framework 6.x. Entity Framework 7 will give you familiar developer experience to previous versions of EF, the user can still work with DbContext, DbSet, etc.

EF7 is much more lightweight than previous versions and is built from the ground up to work great in the cloud (using ASP.NET vNext) on devices (i.e. in universal Windows apps) as well as in traditional .NET scenarios.

Important features of Entity Framework 7:

Lightweight and extensible

Instead of use existing Entity Framework 6 APIs, Team decide to start developing from the scratch. You can use only that extensions which are useful to your project. The pattern and concept remain same to use Entity Framework. You can use DbContext/DbSet same way as you are currently using. The advantage of extensible is you can replace and extend it.

New Platforms

EF is most popular ORM that currently includes applications built with technologies such as WPF, WinForms and ASP.NET. After looking at future Microsoft has decided to support remaining platforms where .NET development is common. This includes Windows Store, Windows Phone and the Cloud Optimized .NET.

New Data Stores

Entity Framework was clearly tied with relational data stores. Now onward EF provide great support to non relational data stores also. Relational & non Relational, like Azure table storage.

Optimized Query generation

Based on people’s higher request on EF uservoice “Improved SQL Generation“, Diego Vega (Engineering Manager, Entity Framework) responded positively and start working on this feature. On next or may be final release they will include this feature. EF7 will generate much simpler SQL queries than EF6 for the most common scenarios.

Code first only

Finally Microsoft Team retired EDMX in Entity Framework 7. You can read Rowan Miller’s article EF7 – What Does “Code First Only” really mean. If you still love edmx, you would love to read What about EDMX when EF7 arrives? written by Julie Lerman.

Batch Update

No longer need to use EF batch update utilities to perform batch operations because EF7 has inbuilt support for that. EF 7 no longer send individual command for every insert/update/delete statement. EF 7 will batch multiple statements in single round trip to the database.

Unique Constraints

EF 7 allows you to identify additional unique keys within your entities in addition to the primary key. You can then use these alternate keys as the target of foreign key relationships. A unique constraint is introduced for each alternate key in the model.

Entity Framework Code First

The code first approach, part of the Entity Framework 4.1, was the last workflow Microsoft introduced. It lets you transform your coded classes into a database application, with no visual model used. Of the three workflows, this approach offers the most control over the final appearance of the application code and the resulting database. However, it’s also the most work. And it presents the biggest obstacles to communicating well with non-developers during the initial design process.

With the code first workflow, you also need to write glue code in the form of mapping and, optionally, database configuration code. However, even in this respect, the workflow provides developers with significant advantages in flexibility. You know precisely what is going on with the underlying code at all times, which is a huge advantage when working with enterprise systems. The cost of this knowledge is equally huge; it takes considerably longer to develop the application.

A code first workflow is the only realistic solution when an organization decides on a code focus approach for an existing database. However, in this case, the developer must do the reverse engineering of the database and create classes that reflect the database design as it exists. Microsoft does provide some assistance to the developer to perform this task in the form of the Entity Framework Power Tools, but you should expect to still end up tweaking the code to precisely match the application requirements and the underlying database.


Entity Framework Model First

The model first workflow was originally introduced as part of the Entity Framework 4.0 to make it possible for a developer to use a designer to create a database from scratch. The designer lets you visually define the database using an approach much like the technique for creating forms for applications. You select database elements from the Toolbox, perform some configuration, and then run a few commands to create the database. It’s a little more complex than that, but not much. From an ease of design perspective, the model first workflow is definitely the way to go.

When using the model first approach, the designer takes over the task of creating the classes that interact with the database. The designer relies on the .EDMX file it generates to maintain the design specifics. You can change the output of these classes through configuration settings, or modify the model designer through the .EDMX file or by creating extensions to the design. These are advanced techniques though and tend to become quite complicated after a while; it’s often a lot easier to use one of the other workflows to overcome the limitations of this approach.

Most developers use the model first workflow on new projects where there’s no existing database or code base. One benefit of using this approach is that it makes it easier to help others see the design as you put it together. The designer provides a prototyping tool of sorts that can provide understandable output for meetings with people who wouldn’t have the skills required to understand code, but who can understand a block diagram. The overall advantages of this approach are speed of design when working with a new database and the ability to communicate with non-technical groups.

Entity Framework Database First

The Entity Framework was originally designed to make working with existing databases easier. As a result, the database first workflow is the most polished version of the three options. Given an existing database, the Entity Framework can analyze it, provide you with options for importing partially or all of the structure, and then create the model automatically. The underlying objects are automatically generated as well. All that developer really needs to worry about is creating the application itself; the database access is pretty much handled by the Entity Framework. In general, this feature of the Entity Framework works incredibly well and is quite fast

The most significant advantage of the database first workflow (besides being incredibly fast) is its consistency. Having a means of producing consistent model is important in a large team setup. Team members can work on various parts of the database and the resulting model will still go well together because it was produced in a consistent manner in the first place.

Be aware, this is also the least flexible method of creating the underlying objects used by the .NET Framework as part of your application. The development team gains the least knowledge of precisely how things work. In fact, the objects begin as a black box that could cause you problems later if the Entity Framework encounters some oddity in the original database. To make changes to the underlying objects, you also have to rely on working with extensions, rather than modify the code directly, because the automation overwrites any changes you make. This leads to problems of figuring out just which file to look in for changes.

Copyright © All Rights Reserved - C# Learners