EF7 – v1 or v7?

Artículo
10/27/2014

A while ago we blogged about EF7 targeting new platforms and new data stores. In that post we shared that our EF6.x code base wasn’t setup to achieve what we wanted to in EF7, and that EF7 would be a “lightweight and extensible version of EF”.

That begs the question, is EF7 the next version of EF, or is it something new? Before we dig into the answer, let’s cover exactly what’s the same and what’s changing.

What’s staying the same?

When it comes to writing code, most of the top level experience is staying the same in EF7.

You still create a class that derives from DbContext and has DbSet<TEntity> properties for each type in your model.
You still use LINQ to write queries against your DbSet properties.
You still Add and Remove instances of types from your DbSet properties.
There are still DbContext.ChangeTracker and DbContext.Database properties for accessing change tracking information and database related APIs.

An example

For example, this code looks exactly the same in EF6.x and EF7.

 using (var db = new BloggingContext())
{
 db.Blogs.Add(new Blog { Url = "blogs.msdn.com/adonet" });
 db.SaveChanges();
 
 var blogs = from b in db.Blogs.Include(b => b.Posts)
             orderby b.Name
             select b;

 foreach (var blog in blogs)
 {
  Console.WriteLine(blog.Name);
  foreach (var post in blog.Posts)
  {
   Console.WriteLine(" -" + post.Title);
  }
 }
}

What’s changing?

While the top level API remains the same (or very similar), EF7 does also include a number of significant changes. These changes can be grouped into a series of buckets.

Bucket #1: New Features

One of the key motivations behind EF7 is to provide a code base that will allow us to more quickly add new features. While many of these will come after the initial RTM, we have been able to easily implement some of them as we build out the core framework.

Some examples of features already added to EF7 include:

Batching of updates for relational databases means that EF7 no longer sends an individual command for every insert/update/delete statement. In many situations EF7 will batch multiple statements together into a single roundtrip to the database. We’ll expand the capabilities of batching in future releases too.
Unique constrains 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.

Bucket #2: Behavior Changes

EF6 and earlier releases have some unintuitive behavior in the top level APIs. While the APIs are staying the same, we are taking the opportunity to remove some limitations and chose more expected behavior.

An example

An example of this is how queries are processed. In EF6.x the entire LINQ query was translated into a single SQL query that was executed in the database. This meant your query could only contain things that EF knew how to translate to SQL and you would often get complex SQL that did not perform well.

In EF7 we are adopting a model where the provider gets to select which bits of the query to execute in the database, and how they are executed. This means that query now supports evaluating parts of the query on the client rather than database. It also means the providers can make use of queries with multiple results sets etc., rather than creating one single SELECT with everything in it.

Bucket #3: Simple, lightweight components

Under the covers EF7 is built over the top of a lighter weight and more flexible set of components. Many of these provide the same functionality as components from EF6.x, but are designer to be faster, easier to use, and easier to replace or customize. To achieve this they are factored differently and bare varying resemblance to their counterparts from EF6.x.

An example

A good example of this is the metadata that EF stores about your entity types and how they map to the data store. The MetadataWorkspace from EF6.x (and earlier versions) was a complex component with a difficult API. MetadataWorkspace was not built with a lightweight and performant O/RM in mind and achieving basic tasks is difficult. For example here is the code to find out which table the Blog entity type is mapped to:

 using (var context = new BloggingContext())
{
 var metadata = ((IObjectContextAdapter)context).ObjectContext.MetadataWorkspace;
 var objectItemCollection = ((ObjectItemCollection)metadata.GetItemCollection(DataSpace.OSpace));
 
 var entityType = metadata
  .GetItems<EntityType>(DataSpace.OSpace)
  .Single(e => objectItemCollection.GetClrType(e) == typeof(Blog));
 
 var entitySet = metadata
  .GetItems<EntityContainer>(DataSpace.CSpace).Single()
  .EntitySets
  .Single(s => s.ElementType.Name == entityType.Name);
 
 var mapping = metadata.GetItems<EntityContainerMapping>(DataSpace.CSSpace).Single()
  .EntitySetMappings
  .Single(s => s.EntitySet == entitySet);
 
 var table = mapping
  .EntityTypeMappings.Single()
  .Fragments.Single()
  .StoreEntitySet;
 
 var tableName = (string)table.MetadataProperties["Table"].Value ?? table.Name;
}

In EF7 we are using a metadata model that is simple to use and purpose built for the needs of Entity Framework. To highlight this point, here is the EF7 code to achieve the same thing as the EF6.x code listed above.

 using (var db = new BloggingContext())
{
 var tableName = db.Model.GetEntityType(typeof(Blog)).Relational().Table;
}

Bucket #4: Removal of some features

Removing features is always a tough decision, and not something we take lightly. Given the major changes in EF7 we have identified some features that we will not be bringing forward.

Most of the features not coming forwards in EF7 are legacy features that are only used by a very small number of developers.

Multiple Entity Sets per Type (MEST) is a legacy feature that allows you to use the same CLR type for multiple entity sets (i.e. you have a Products and RetiredProducts table that are both mapped to the Product class). This feature was never supported thru the DbContext API or code-based models. Although possible, it was difficult to use from the EF Designer too. Requirements like this are better solved with inheritance.
Very complex type to table mappings were possible in EF6.x. For example you could have an inheritance hierarchy that combined TPH, TPT, and TPC mappings as well as Entity Splitting all in the same hierarchy. This sounds great, but is one of the major contributing factors to the complexity of the MetadataWorkspace in EF6.x. In EF7 there will be cases where your CLR types need to more closely match your table structure.

Some of the features we are retiring because there is already another (we believe better) way of doing things. While we’d love to continue pulling everything forward, we need to balance time, resources, and the cost of adding support for highly requested features as we move forward. To be able to continue devloping and improving the stack we need to shed some of the baggage.

Retiring the EDMX model format in favor of code-based modeling is perhaps the most significant change in EF7. You can read more about this change and the reasoning behind it in our recent post on the topic.
ObjectContext API was the primary Entity Framework API until DbContext was introduced in EF4.1. Since then we have seen DbContext quickly become the API of choice for EF developers. Given this, and the much cleaner API surface that DbContext provides, we are not bringing ObjectContext forward into EF7. Of course, the important features you needed to drop down to ObjectContext API for in the past will be available from DbContext API, but factored into a cleaner API surface.

Not everything will be there in the initial release

Because much of the core of EF7 is new, the first release of EF7 isn’t going to have all the features that are required for all applications. There is always a tension between wanting to ship quickly and wanting to have more features in a given release. As soon as we have the core framework and basic functionality implemented we will provide a release of EF7 for folks to use in applications with simpler requirements. We’ll then provide a series of quick releases that add more and more features.

Of course, this means EF7 isn’t going to be usable for every application when it is first released, and for that reason we are continuing development of EF6.x for some time and expect many of our customers to remain on that release.

An example of this is lazy loading support, we know this is a critical feature for a number of developers, but at the same time there are many applications that can be developed without this feature. Rather than making everyone wait until it is implemented, we will ship when we have a stable code base and are confident that we have the correct factoring in our core components. To be clear, it's not that we are planning to remove lazy loading support from EF7, just that some apps can start taking advantage of the benefits of EF7 before lazy loading is implemented.

So, is it a v1 or a v7?

The answer is both. There were actually three options we discussed in terms of naming/branding for EF7:

Call it v7 of Entity Framework – Given the top level API and patterns are the same as past releases, this is in many ways a major version of the same product. Per semantic versioning, breaking API changes and removal of features is a permissible (and inevitable) part of major releases.
Create a sub-product under Entity Framework – This option was somewhat of a middle ground. While the developer experience is undoubtedly EF, creating a sub product would help communicate that there are also a significant number of changes. This would be akin to the “Entity Framework Everywhere” name we used for the initial design document we published in CodePlex.
Call it something new and make it v1 – Given the number of changes, we did consider naming it something new.

We decided that once you start writing code, this feels so much like Entity Framework that is really isn’t something new (that ruled out option #3). While there are going to be some nuances between the v6 and v7 transition that need to be documented and explained, it would ultimately be more confusing to have two different frameworks that have almost identical APIs and patterns.

Options #1 and #2 both seem valid to us. Our ultimate conclusion was that #1 is going to cause some confusion in the short term, but make the most sense in the long term. To a lesser extent we’ve tackled similar hurdles in the past with the introduction of DbContext API and Code First in EF4.1 and then the move out of the .NET Framework in EF6 (and subsequent duplications of types, namespace changes, etc.). While these were confusing things to explain, in the long term it seems to have been the correct decision to continue with one product name.

Of course, this is a somewhat subjective decision and there are no doubt folks who are going to agree and some who will disagree (there are even mixed opinions within our team).

Comments

Anonymous
October 27, 2014
The comment has been removed
Anonymous
October 27, 2014
I'd vote for #1 (if this was a democracy). As you say, breaking changes and removal of features is permissible in a major release number.
Anonymous
October 27, 2014
+1 for Option 3. Learn from EDMX and CodeFirst, it is confusing for a lot devs. Maybe now good time to clean thing up. And also at some point breaking compatibility happen. When that happen, people update the from NuGet will not break too much.
Anonymous
October 27, 2014
The comment has been removed
Anonymous
October 27, 2014
The comment has been removed
Anonymous
October 27, 2014
Please don't do it. It will be a big mistake for the future of EF itself. It will leave EF missing many of the features that many people use in some way or another. Only thing sane is either one of two things:

Do not realease anything until all features are completed (excluding features that are left out on purpose like EDMX)
Release it as CTP or beta, but don't call it EF7 The 7 in EF7 should mean >6 not !=6. It is ok to break changes in mayor versions but this changes should make the software better not worse. Releasing EF7 before it's ready will make people upgrade happily only to find out later that is missing many features of 6. When jQuery 2.x replaced jQuery 1.x it stopped supporting old browsers to make it easier to mantain, but not at the cost of loosing core features. Please take that into account before it is too late

Anonymous
October 27, 2014
Do not confuse developer and save your popularity. Name it EF 7
Anonymous
October 27, 2014
my take:

don't change the name, it's a cool and popular name
about lazy loading: please don't release a newer version which has less important features than the previous one.

Anonymous
October 27, 2014
With great, very stabile and mature O/RMs around, like NHibernate and LLBLGen, given the huge resources available to Microsoft, there are no excuses for not producing a better O/RM, with more features than the above 2. EF 7 is the 4'th atempt at Microsoft to produce a decent ORM - LINQ2SQL, EF1 db-first, EF code first, now this.. :) LLBLGen, with only 2-3 developers has produced a much better ORM, earlier and with a bettetr designer, years ahead of Microsoft. Removing lazy loading? :) This must be a joke.. The issue is that Microsoft never took the business of producing an ORM too seriously, and was always behind in term of features compared to mainstream products like NHibernate.. :)
Anonymous
October 27, 2014
What about transparent proxies like NHibernate has them? This allows DbContext.Load<Customer>(id: 10) to never hit the database. This is super useful when you need to set a foreign key based member to some value, yet you want/need to keep using a Customer object instead of its ID. The more complicated a business logic layer the more this feature matters.
Anonymous
October 27, 2014
The comment has been removed
Anonymous
October 27, 2014
I'd personally vote for #3... EntityFramework really has a stigma around it, and as a consultant, there have been numerous times I have suggested EF, only to have clients scrunch their nose at it. The Vote of No Confidence way back in the day (along with the near-decade amount of time it took for your team to finally get it right) did not do you any favors. I say you've soiled your first diaper and it's ready for a new one. :)
Anonymous
October 27, 2014
"Very complex type to table mappings were possible in EF6.x. For example you could have an inheritance hierarchy that combined TPH, TPT, and TPC mappings as well as Entity Splitting all in the same hierarchy." Hopefully you can use any combination of one of (TPH, TPT, TPC) with entity splitting. My biggest peeve with NHibernate is that union subclass mapping (TPC) is mutually exclusive to entity splitting. It's the most natural way of dealing with one particular scenario I have to handle. When I discovered EF6 could do it I was like ^_^ but if you remove it I'll be like (╯°□°)╯︵ ┻━
Anonymous
October 27, 2014
Please release EF 7 as a new Nuget package so that projects with EF6.x don't accidently upgraded.
Anonymous
October 27, 2014
why there is one more metadata model, is it is not possible to use ASP.NET MVC metadata model? is it possible to extend the metadata model?
Anonymous
October 27, 2014
Are there any ideas on the timeline for EF7?
Anonymous
October 27, 2014
Speaking as an ISV in the .NET data space (we make VistaDB) I'd heavily encourage you to go with option #3. The changes in EF 6 have made it our #1 support problem with customers - nearly 80% of the support tickets we get are from people who can't get the EF provider detection to work for database first. That tells us that 1) Database first is quite essential to developers and 2) the existing provider detection (that hard-codes Microsoft SQL Server in the list but no one else) is a problem. As we look at what's coming with EF 7 where we'll have to create an entirely new provider architecture and people will lose the database-first approach they're used to (complete with the ability to refresh from the database as they update their models) it's going to create an entirely new set of procedures developers need to follow to get started. This confusion is going to fall on us - even more support tickets that have to go two rounds of "what exact version is your EF library" and "have you installed the latest EF tooling." I would heavily encourage you to change the name. Consider the number of times in the previous thread on EDMX being abandoned that it was stated "it's OK - we'll keep developing and supporting 6.x". That, coupled with EF 7 dropping features the team knows are important, says that this is really a new effort. I do believe that for some people what you're trying to do with EF 7 is useful - adding non-relational support, for example - but there are masses of people happily using EF 6 today as it is for RDBMS access that will feel abandoned. As our customers have consumed this information their conclusion has often been that EF 7 isn't for them, but EF 6 is obsolete, so it's time to go to something else entirely. It won't matter how many times you say that you're still patching EF 6, since you've shipped a new major release number everyone's been trained over decades that means the old one's days are numbered. I would suggest this isn't in your team's interest - it's time to call EF 7 something new, some name that shows it's a new vision that's starting fresh with a focus on non-relational data. That will give you the time you need to mature it.
Anonymous
October 27, 2014
The comment has been removed
Anonymous
October 28, 2014
Let me just say "WCF Data Services" and "OData". The same confusion about versions and what is supported in what is present there too: v5.x supports OData v1-v3, v6.x supports OData v4, not compatible with v1-v3. Both are developed in parallel (both receive fixes on a regular basis), like what the EF team suggests here: EF7 will have new mapping API, new behavior, EF6 will stay with the old mapping API/files, old behavior.
Anonymous
October 28, 2014
Based on the last EF upgrade dev/qa/release cost, we've minimized EF usage over time by directly querying the underlying 100+ tables in our application. EF works great when the structure of the tables is rapidly changing, but a it's now a mature application with little DB changes each year and so EF is an ongoing maintenance cost.
Anonymous
October 28, 2014
@Diego & @Brian Sullivan – Just to reiterate the point of this isn’t that lazy loading is going away in EF7, just that when we have a stable core framework we’ll publish it for some developers to use even before we have lazy loading enabled. Folks that need lazy loading should keep using EF6 until we have EF7 a bit more ‘padded out’. Of course, we aren’t going to start pushing EF7 as the ‘go to version’ until it has the basic set of features required for a good O/RM (which includes lazy loading). @Diego - Regarding proxies, I’m not sure exactly what your comments refer to but in EF7 we are looking at a Roslyn based compile time step to replace the need to create dynamic proxies at runtime.
Anonymous
October 28, 2014
@Rick Dailey & @Andrei – Glad it makes sense to you. It’s definitely not a perfect option, but we felt like it was the best one.
Anonymous
October 28, 2014
@soeleman – Updating the Entity Framework package and getting a number of breaking changes is definitely the downside of Option #1. We have some thoughts around this, and will probably pop an ‘are you sure you want to do this’ readme when we detect EF7 being installed as an upgrade. Even when we have an ‘initial release’ that is ready for use in simple apps, we’ll probably still have the package be pre-release on NuGet until has the basic set of features required for a good O/RM and is a viable alternative to EF6. We’re still working thru this, and we’ll be able to make better decisions when we get closer to the time.
Anonymous
October 28, 2014
The comment has been removed
Anonymous
October 28, 2014
@Carlos Muñoz Rodriguez & @Andrew – I’ll just copy/paste a previous comment that addresses this one. I think we agree… “Even when we have an ‘initial release’ that is ready for use in simple apps, we’ll probably still have the package be pre-release on NuGet until has the basic set of features required for a good O/RM and is a viable alternative to EF6. We’re still working thru this, and we’ll be able to make better decisions when we get closer to the time.”
Anonymous
October 28, 2014
@George – I’m not going to disagree with you, we have a mixed past :)… I think our plans for EF7 have some clear differentiation from the other frameworks you mentioned and I think we have the right team to deliver on them. Of course this is just my opinion, but I think we’ve seen the current EF team make some big positive changes from EF4.1 onwards (and our adoption/download rates along with community feedback seem to reflect that). Of course, time will tell and our customers will be the judge :). “Removing lazy loading? :) This must be a joke..” – I think you misunderstood what the blog post was saying, here’s a previous comment on the topic… “Just to reiterate the point of this isn’t that lazy loading is going away in EF7, just that when we have a stable core framework we’ll publish it for some developers to use even before we have lazy loading enabled. Folks that need lazy loading should keep using EF6 until we have EF7 a bit more ‘padded out’. Of course, we aren’t going to start pushing EF7 as the ‘go to version’ until it has the basic set of features required for a good O/RM (which includes lazy loading).”
Anonymous
October 28, 2014
@tobi – I agree this is a useful feature. It’s not going to be on the top of our backlog as there is much higher priority stuff to work on right now, but feel free to open up an item to track it - github.com/.../new.
Anonymous
October 28, 2014
The comment has been removed
Anonymous
October 28, 2014
@MichaelD! – Yep, we have a mixed past and those are things we discussed. It’s a hard one, because we’ve been getting a lot of ‘good reports’ on the more recent releases and so there is part of the ‘brand’ that we don’t really want to throw away – especially since EF7 is continuing in the same direction that we’ve been heading for the last few releases (albeit a bit more bold).
Anonymous
October 28, 2014
The comment has been removed
Anonymous
October 28, 2014
@BenM – Copying some of my previous comments that are relevant to your concern… “Updating the Entity Framework package and getting a number of breaking changes is definitely the downside of Option #1. We have some thoughts around this, and will probably pop an ‘are you sure you want to do this’ readme when we detect EF7 being installed as an upgrade. Even when we have an ‘initial release’ that is ready for use in simple apps, we’ll probably still have the package be pre-release on NuGet until has the basic set of features required for a good O/RM and is a viable alternative to EF6. We’re still working thru this, and we’ll be able to make better decisions when we get closer to the time.”
Anonymous
October 28, 2014
@shiva – Trying to share a metadata model always sounds like a good idea, but we’ve found that in practice you end up with something complex that is sub-optimal for all frameworks. For example, the MVC metadata isn’t at all concerned about mapping to a database etc. EF and WCF Data Services did share a metadata model for some time, but in the end the requirements of those frameworks were so different that we ended up diverging them. What we’ve found is that purpose built metadata is faster and easier to use, and providing translations between them is relatively easy so developers don’t have to worry about converting from one to the other.
Anonymous
October 28, 2014
@Volker von Einem – Copying some of my comments from a previous post… “Disclaimer: this is just current thinking and could all change... We don’t have anything concrete for release dates, but we are targeting early-to-mid next year to have the stack in a stable state where it could be used for simple applications that don’t have complex requirements. It will probably be later next year before we would have EF7 ready to use a proper O/RM in more complex applications (i.e. come early next year it’s not going to have enough critical features for us to want to claim EF7 is a ready-to-go O/RM, but it would be useful for simple applications). Of course, that’s all just our current thinking and we’ll keep folks up dated as we progress – and we’ll continue updates to EF6.x as we go.”
Anonymous
October 28, 2014
@Kendall Miller – I hear you, that’s basically all the reasons we discussed around not going with “Option #1”. I think the important thing is that while the path from EF6 to EF7 isn’t going to be a simple upgrade, we do absolutely see EF7 as the next version of EF and something that folks should eventually use in preference to EF6. What is hard, is that it’s going to take a little while for EF7 to be a sound alternative to EF6 for some folks. In the same way that we have some folks still using EF4 (or even EF3.5) even though EF6 is the recommend release, we want to go the same way with EF7. Once it’s ready, it will be what we push folks to use – in the same way I would advise against starting a new project on EF5 today. I know it’s hard to swallow a ‘just one more major break’ statement. But the provider model in EF6 (and previous releases) has some serious issues. EF7 is a great chance for us to get it right and factor things so that new versions of EF don’t require a major overhaul of existing providers. We will be actively seeking feedback from provider writers once we have things a little more padded out in the provider area.
Anonymous
October 28, 2014
I vote for #1. The increasing number connotes progress, moving forward, a bright future. Starting over at 1 or changing the product name would feel like EF was being abandoned (which it's not).
Anonymous
October 29, 2014
@Dave Sussman – I think the analogy to the confusion around Silverlight/WinForms/WPF vs the Windows 8 apps is actually one of the motivators for making this EF7. EF isn’t dead, there are some big changes coming in EF7 but it’s still fundamentally the same developer experience, coding patterns, etc. One of the key reasons for not introducing a new brand is to avoid this confusion. That said, your points are valid and we’re in a spot where we don’t think there is an obvious choice out of all the options. We want to do the right thing for the long term, and we think that means not having two ‘products’ that have an almost identical top-level API and provide basically the same functionality. Of course, we expect this to be a topic where people opinions fall all over the board and whatever we do there will be plenty of folks who disagree :).
Anonymous
October 29, 2014
@Frans Bouma – I hear you, the downside of this approach is some interim confusion (one of the reasons we’re sharing our thoughts super early). I realize I’m probably not going to sway your opinion, but I think that although there is some confusion for developers who are currently using WCF Data Services, if I walk up to it there is no confusion about what version I should use (I would use 6 since it’s the latest). In the long run, I would argue this is better than creating different products since having ‘WCF Data Services’ and ‘Product XYZ’ that essentially do the same thing would be confusing.
Anonymous
October 29, 2014
@eLabs – Thanks for the feedback and glad to hear it makes sense to you.
Anonymous
October 29, 2014
@Ron – If there are specific things that made the upgrade costly that we could address in the product then we’d love to have your feedback. I’ll just acknowledge the elephant in the room with that statement too – obviously for folks that choose to move their apps to EF7 there will be an upgrade cost (especially for more complex applications). We know that and we didn’t take the decisions around the EF7 changes lightly. We are trying to get a solid platform that will provide a good base for the coming years though.
Anonymous
October 29, 2014
We'd like to not repeat the mistake we made with EF 6 where we assumed we could make a good provider from public info; who should we be in touch with to be sure VistaDB can support EF vNext on release?
Anonymous
October 29, 2014
With EF7 going code-first, developers with an existing database should take a look at visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
Anonymous
October 29, 2014
@Kendall Miller - For sure, and we know we need to do a better job of documentation for provider writers (we definitely dropped the ball in EF6). I wouldn't recommend tackling it just yet as things are still iterating pretty rapidly in the code base. The best place to stay in touch is on our GitHub project. You can just open an issue that we'll use as a discussion to go over details - github.com/.../new. Feel free to open it now if you want and we'll just pop it on the backlog until we have things in better shape for you to start work on.
Anonymous
October 29, 2014
I strongly stand for option 3. The Internet is full of articles, tutorials, podcasts and Q/A about Entity Framework (many of them even not explicitly specifying the version). When a new developer starts with EF and tries searching for some problems he will get at the beginning, he will be overwhelmed with completely outdated content just because EF7 is not an incremental release but a huge redesign with completely different guts and a lot of breaking changes. Most of advanced topics or complex problems will have a different solutions and as you mentioned some features will be missing - that is not how next version is supposed to work. Same goes for books. If I purchase a book for recent version of the product, I will expect that major part of the content will be valid for the next version. Again it does not seem to be the case with EF7. If you don't want to abandon Entity Framework name, please consider at least Lightweight to become the part of the name and go for EFL1. The old EF6.x can live as open source project with EDMX and all the stuff it has right now.
Anonymous
October 29, 2014
@Simon Hughes - I've heard good things about your tool, nice work. Even as we improve our reverse engineer tooling for Code First I don't think we're going to "replace" your tool as your "T4 template directly to the database" approach is different enough from the wizard style approach that I think there will always be folks that prefer it :). We will be addressing some of the gaps in our tooling that your tool currently deals with nicely (most notable performance :)). BTW, some of the info on the page is a little out of date since the integration of 'Reverse Engineer Code First' into the EDMX wizard (in EF6.1) added some capabilities (optional pluralization, table selection, etc.).
Anonymous
October 29, 2014
It MUST be a new name just to avoid the Google problem. Half of the queries end up in EntityFramework 4.x "fixes" that don't apply to v6... imagine how much worse it will be.
Anonymous
October 29, 2014
I'm wondering if EntityDataSource will work with EF7? I need this because I'm using Telerik's RadGrid UI control with large result sets and RadGrid is smart enough to make the filtering work at the database-level if you use an EntityDataSource. Also, I'm wondering if there will be a way to set things like command timeout with the new API. This is something that I needed to do using ObjectContext previously.
Anonymous
October 29, 2014
I'm for option #1. There have been breaking changes in the past. It was a bit of a hassle, but, at least it cleaned up the API. I would rather have a nice clean API and make a few code changes than to have to work with an ugly API forever. As you pointed out, semantic versioning allows for breaking changes on major versions of a product. I see no reason to change the name.
Anonymous
October 29, 2014
The comment has been removed
Anonymous
October 29, 2014
Please make the current status of EF7 known to ISVs so that they start cooking up support for EF7 in their providers. I would like to move over to EF7 now (from the current EF 6.1.1) (already using ASP.NET vNext for web + core stuff) but I am still waiting for the Postgres folks to start working on an EF7 compatible provider (I am on Linux).
Anonymous
October 30, 2014
#3 it is clearly a different product.
Anonymous
October 30, 2014
It's a new version of an existing product, but add something unique as a prefix (like you did with CodeFirst) to make it searchable.
Anonymous
October 30, 2014
Does Entity SQL go away in 7? For some reason, I'm thinking that it will. Not sure what that would mean for things like EntityDataSource. I guess it would go away.
Anonymous
November 03, 2014
We still use DBML (with direct xml changes) PLUS DACPAC approach, namely because our app is more real-time so we do not like any magic uder cover (like lazy loading) and we like to have things under control. But namely because of Async and multiple DB vendor support we are tempted to move towards EF. From your blog I've got a feeling, that EF7 will be less heavy weight (bloated?), so maybe closer to old Linq2Sql (that we like). What do you think about migration path from Linq2Sql to EF7 ?
Anonymous
November 03, 2014
Hey, why don't you call it EF10? :-)
Anonymous
November 04, 2014
@Marc Brooks – I agree that is definitely going to be a challenge, as you mentioned it has already been an issue with past releases where we made significant changes. On the flip side, it is always going to be an issue when you evolve a product – but I agree EF7 will be a particularly bad case. Our plan is to put headers on all the existing content that our team owns, of course that doesn’t help with stuff that isn’t maintained by our team.
Anonymous
November 04, 2014
@Jon - Honestly, I'm not sure if we'll create/update Entity Data Source for EF7. It would absolutely be possible, but whether or not we do it would be based on customer demand relative to other requests. If demand is low and we don't do it, it would be a great contribution or third party project. Yes, we’ll have a way to configure command timeouts etc. Glad that the ‘EF7’ direction sounds good to you – thanks for the feedback :).
Anonymous
November 04, 2014
@Borgdylan – We will be working with third parties in the near future (we’ve talked thru EF7 with some of them already), but at this stage it’s too early for folks to start working on providers and tooling because the code base is iterating so rapidly. Once things are stabilized a bit more, we’ll start getting folks ramped up.
Anonymous
November 04, 2014
@Chris Marisic, @Betty – Thanks for the feedback, as you can probably tell from the comments there isn’t a clear winner among developers (or within our team for that matter).
Anonymous
November 04, 2014
@Jon – ESQL in its current form will go away, we will have an API for building queries without referring to strongly typed CLY properties/classes though. We need this to support ‘shadow state’, which is a new feature that allows you to have properties in your model that aren’t part of your CLR class.
Anonymous
November 04, 2014
@Jiri – Yes, ‘less bloated’ is a fair assessment :). I think migration from LINQ to SQL to EF7 is going to be much more feasible that past versions of EF (though of course we haven’t actually go to the stage of digging into the migration experience just yet as we are still pretty early in the development process).
Anonymous
November 04, 2014
@Klaus Even Enevoldsen – We did actually joke about calling it EF8… guess you’re just taking it a step further :).
Anonymous
November 04, 2014
Thanks @Rowan, I opened issue 1007 as a placeholder for a discussion around providers: github.com/.../1007
Anonymous
November 04, 2014
I would really appreciate update mechanism in the EF7. Something simple as context.Products.Update(product). It would scan product, including all its references and update. Today we have two options (both are pain) 1, Sync whole trees of dataobjects manually or 2, develop some generic mechanism using reflection to compare trees of dataobjects
Anonymous
November 05, 2014
We cannot move away from VS 2012 sooner because of third party dependency. But we can adopt EF7 quickly. Question is, whether EF7 will be supported on Visual Studio 2012 with all Toolsets ???
Anonymous
November 05, 2014
The comment has been removed
Anonymous
November 05, 2014
@sac_ssn – You can currently use the runtime in VS2012 and we want to try and keep the dependency at .NET 4.5 (though I can’t promise that will be the case come RTM… just what we’re aiming for). Regarding any tooling we do, it will depend on the cost and demand for particular versions. Most likely it will just be VS2013 and later, but we may do VS2012 if it doesn’t require a lot of extra work.
Anonymous
November 05, 2014
Currently we are trying to use github.com/.../GraphDiff to transfer a state from our detached objects to the context. Even though I'm not sure that it is good idea. Our current approach is to transfer state to the UI. UI modifies the state and sends it to the service. The new state is transformed to poco tree and using GraphDiff we reflect new state to the context. Validation of the new state is quite pain. Mainly in delete scenarios where the new state just does not contain the entity in the collection. Validation must check if it is allowed to remove the entity but we don't have list of entities which to be deleted. Another approach could be something like CQRS (sending deltas not new state) but it has also its problems. I'm just disappointed that I don't see any easy way how to do update scenarios. In Julia Lerman's book DbContext(page 88) she is describing more ways how to do it. It is pain to work with all of them. :-(
Anonymous
November 10, 2014
@Vaso - Yep, it is a very difficult problem to solve well. Unfortunately, frameworks that try to "just take care of everything for you" tend to work well for very simple scenarios but quickly fall over and you end up writing lots of complex code yourself. An example of this is the 'self tracking entities' feature that we tried on the EF team. The first step for us in EF7 is to work on getting the right set of lower level APIs to make things a little less painful.
Anonymous
November 12, 2014
The comment has been removed
Anonymous
November 12, 2014
yes option# 1. it should be v7 of Entity Framework
Anonymous
November 12, 2014
I take it, you're not going to continue supporting EF6 and the features removed for EF7. Therefore, it should be called EF7. Changing the name to XX1 would be pointless, because you would be effectively abandoning EF. Good decision.
Anonymous
November 12, 2014
I'm really curious as to the eventual future of this "new" ORM. I currently have a fairly complicated project created around EF 6.1 that uses CodeFirst against an existing fairly legacy DB. I have a fairly customized bootstrap process which uses reflection to identify entity types dynamically (to support mixing plugin entities within the same context) as well as custom conventions which manually manipulate the underlying metadata to support such things as mapping scalar- and tabular-user defined functions, having contributed code to EF6 to make this possible. I'm worried that EF7 will make some of this impossible and orphan our solution. With EF7 going exclusively "Code First" is there consideration for supporting the API better in "Database First" scenarios? Is stored-procedure, UDF and TVF mapping on the roadmap at all?
Anonymous
November 13, 2014
I know this won't happen, but heck, if you've finally realised that EF6 is so bad you need to start again, why doesn't Microsoft swallow it's pride, embrace the new open source wave completely and dump EF for NHibernate. It's still way ahead in most areas of EF, but does need some modern features. The 2 - 4 part-time developers could do with some help to add async support.... Of course, this won't happen, so if EF7 is going to be so awesome for the cloud, use the EF7 rework to introduce a similar style to NHibernate to aid migration. For example, the dbContext is very similar to the NHibernate Session. The fact you have all your entity manipulation logic on dbSet makes it harder to have a common repository pattern that can have different implementations.
Anonymous
November 17, 2014
@Matt – There is still the concept of a provider. Our team most likely won’t work on a DB2 provider, that would be something a third party would provide.
Anonymous
November 17, 2014
@ahmed & @Todd – Good to hear the direction sounds good to you.
Anonymous
November 17, 2014
@Halo – What you should find is that those custom conventions, dynamic type discovery etc. are quite a bit easier to implement on EF7 (not just yet though as there are still some pieces missing from the current code base). Non-table objects are definitely on the list of things to implement, we’re just getting up and running against tables first.
Anonymous
November 17, 2014
The comment has been removed
Anonymous
November 18, 2014
@rowan >are you after Add/Remove/etc. methods directly on the context rather than the set? If so, that is already in EF7. Just to dial back my previous semi-rant; it's good that you guys are fixing some of the problems in EF as I have looked at it at each previous version and decided "nah, stick with NH". When async came along, that was when I had to look again at the two stacks but NH still came out on top due to the problems you've mentioned in the past re: performance. If you fix the sql performance/2nd level caching etc. then EF may start to stack up for the 80% of cases where you need an ORM as opposed to now where (IMO) NH wins out. My comment about making EF similar to NH came from some design notes I read recently where it was decided to drop Add/Remove etc. from the dbContent and keep them on the dbSet. As an NH user, I've never really understood why you needed dbSet, but I'm sure its for a good reason. However it's always been a pain point when I've created my repository patterns that either have an NH implementation or an EF implementation, therefore IMO, NHibernate is the defacto serious standard in .NET for an ORM, and if EF wants to take it's place then it should be set up to ease migration from one product to the next, and will make this easier if it adopts similar patterns where they plainly exist in both systems, i.e. Unit of Work via dbContext or ISession where you manipulate the UoW directly instead of through dbSet.
Anonymous
November 18, 2014
@Rowan Our database changes little each major release; with 2-10 new tables, a few new columns added to tables, a few extended character columns, etc. EF worked for us during the first few versions of our application given the large number of database changes, but now with a mature application and a slowly changing database it is an ongoing maintenance cost. This led us to using EF for a smaller and smaller subset of database operations and going through .NET for db read queries, most of the update queries and delete queries. We use a few stored procedures for infrequently used multi-step database operations. Developer time writing SQL is minimal since basic db CRUD operations have already been written for older solution releases. Our developer effort tests for database access include

add a column to an existing table and implement read, write and update operations on that column
Add a new child table to the database and implement read, write, update and delete operations on that table
Add a new stored procedure
Change the data type for a column, such as integer to double precision float
... The developer effort tests compare the cost of using EF for implementing a database change versus using basic .NET database classes for it. In most cases EF costs more in terms of developer time. We also add in the developer time/qa time cost of an EF upgrade to the ongoing yearly EF cost. We avoid whole object at a time database operations other than adding a new object to the database. It helps avoid doing db cursor-like foreach X in Y loops in C# code. Our application is engineering based and does not have a large designed up-front object structure.

Anonymous
November 21, 2014
What is the alternative for TPT and TPH in EF7? In my opinion, those are very important features for building an object oriented structure of classes. Thanks.
Anonymous
November 23, 2014
Does DBInterception / IDbCommandInterceptor / others from EF 6 exists in EF 7 ( or EF 1) ?
Anonymous
November 25, 2014
@Graham Bunce – We discussed this recently and decided to keep them on the context.
Anonymous
November 25, 2014
@Ron – I’m definitely not going to tell you to use EF if you have a data access approach that works well for you and your team. It sounds like you prefer the lower level access over the O/RM approach in general and that is definitely a valid option.
Anonymous
November 25, 2014
@Satyajeet1 – We will have inheritance mapping in EF7. What we will probably do though is make EF7 available for use in simple apps before all the basic O/RM features are available. We won’t be pushing it as the ‘go to release’ until it has these things though.
Anonymous
November 25, 2014
@Andrei Ignat – APIs that let you achieve the same thing will exist, but they will likely look very different.
Anonymous
February 17, 2015
I'm very pleased with the direction you are taking EF7. I've refused to use .EDMX all along, and look forward to seeing better support for "code first".
Anonymous
March 05, 2015
This roadmap smells to me like Microsoft cut off the budget on EF and now you are trying to prune it to save it....... Mutilating the EF is not going to ge you there. Gambling on the "easy way out" which is putting all resources into CodeFirst is the actual death of Entity Framework. Code First can only be used in very limited scenarios. In enterprise level application development CodeFirst is useless. Companies design their databases based on Corporate requirements accross all applications that will run on that database: taking into account Normalization, Denormalization, performance and other DB design principles. In other words the design and implemtation of the database is NOT done by Software Developers but by DB experts or DBA's. This means that many applications access the same database and the schema cannot be changed by applications or developers. By leaving CodeFirst as your only choice; you basically turned entity framework into a "script kiddie toy"..... Not a professional ORM. This whole EF mutilation process smells to me like a "Silverlight show".... DO NOT USE EF FOR ENTERPRISE LEVEL APPLICATIONS!!!! YOU'VE BEEN WARNED!!!!
Anonymous
March 05, 2015
Just to finish up my commments on this blog: I kind of suspected the end of EF was near when you introduced the "Command Interceptors" which to me said "we give up and we are not capable of generating clean, flat, performant SQL so write it yourself" which defeats the purpose of EF..... Deffinetly EF team is lacking real leadership and expertise on what professional application development means today.... I hear alot of students and such advocating to CodeFirst; but I have NEVER seen a real software company use it. It simply is not usable when the database is shared amongst other applications and teams.... Good luck and good bye to EF!
Anonymous
March 13, 2015
@Jonathan Alfaro - EF is definitely not being cut off, quite the opposite, EF7 is a big investment to get EF in a state where it can be a relevant data stack for the coming years. Regarding Code First, it would be great if you could take a read of this post - blogs.msdn.com/.../ef7-what-does-code-first-only-really-mean.aspx. As the post elaborates on, Code First can totally be used against an existing (DBA created) database, in fact that is already true in EF6.1 where the same wizard that creates an EDMX model can also create a Code First model. Code First is a bad name, you'll see we tend to use "code-based modelling" or similar terms these days.
Anonymous
April 29, 2015
How about calling it EF8? You can signify number of changes by skipping a number. Or EF10 :)
Anonymous
May 07, 2015
How do you set the precision of float fields now in ms sql?
Anonymous
May 12, 2015
@Boris - We actually did consider skipping a number... I'm not sure it really helps that much though. I think going down the route of a new version number of the existing name suffers the confusion around breaking changes problem.
Anonymous
May 12, 2015
@Ryan - At the moment you would just specify the appropriate data type for SQL Server. We are working thru this at the moment though and working out what 'higher level concepts' it makes sense to have APIs for.
Anonymous
May 26, 2015
Good to know EF is maturing. Hope it would address

Runtime dynamic column output (Runtime Complex Types) block due to which we are not able to consume benefits of FTS, Dynamic queries, etc.
Expecting WCF DS using EF7 would return meaning full ENGLISH error messages than using fiddler etc.
Add code snippets and advanced auto completions for linq queries in VS IDE.
In reality add real VB support than only C#. RV

Anonymous
August 14, 2015
most important: are you going to continue to support Entity Framework (ie, v6) ?
Anonymous
September 03, 2015
It seems that default conventions for table names have been changed in EF7. Previously it "pluralized" the names of corresponding classes (so if I have User class - then corresponding name of table by default was "Users"). Now it does not. Is it by design? Is there a way to return back "pluralizing" for all tables at once? I know about a possibility to specify a concrete table name for each entity separately but it would much more easy to make such behavior (pluralizing) the default one.
Anonymous
October 19, 2015
@spongman – Yes, EF6.x is going to be supported for some time and we are going to continue small improvements and bug fixes to the code base. – so swapping to EF7 is not going to be required (or even recommended) for everyone right away.
Anonymous
October 19, 2015
@Sergiy – Yes, we removed pluralization because it caused a lot of issues in EF6. There isn’t a first class way to turn it on (since we don’t ship a pluralization service any more) but if you are willing to write your own pluralization logic (or plug in a third party one) then you can easily iterate over the types in the model and specify a table name for each one.

Compartir a través de

EF7 – v1 or v7?

What’s staying the same?

What’s changing?

Bucket #1: New Features

Bucket #2: Behavior Changes

Bucket #3: Simple, lightweight components

Bucket #4: Removal of some features

Not everything will be there in the initial release

So, is it a v1 or a v7?

Comments

Recursos adicionales