EF7 - New Platforms, New Data Stores

Artikel
05/19/2014

At TechEd North America we were excited to announce our plans for EF7, and even demo some very early features. This post will cover the announcements we made during the session. You can also watch the recorded session from TechEd (the EF7 content starts at 46:40). When watching the demos please bear in mind that this is a very early preview - not all the features shown are even submitted into the main code base yet.

Entity Framework Session @ TechEd North America 2014

EF7 Enables New Platforms

Entity Framework is a popular data access choice for traditional client and server applications that target the full .NET Framework. This includes applications built with technologies such as WPF, WinForms and ASP.NET. As we look to the future, we believe there is value in providing the same programming model for data access on the remaining platforms where .NET development is common. This includes Windows Store, Windows Phone and the Cloud Optimized .NET that was announced at TechEd. EF7 will work on all of these platforms as well as Mono, on both Mac and Linux.

For Windows Phone and Windows store, the initial goal is to provide local data access using EF. SQLite is the most common database of choice on devices, and will be our primary story for local data with EF7. The full provider model will be available though, so other data stores can be supported also.

In the TechEd session you can see a demo of EF7 being used in a Universal App (targeting Windows and Windows Phone) starting at 1:04:00.

EF7 Enables New Data Stores

While parts of Entity Framework are clearly tied to relational data stores, much of the functionality that EF provides is applicable to many non-relational data stores too. Examples of such functionality include change tracking, LINQ, and unit of work. In EF7 we will be enabling providers that target non-relational data stores, such as Azure Table Storage.

We are explicitly not trying to build an abstraction layer that hides the type of data store you are targeting. The common patterns/components that apply to most data stores will be handled by the core framework. Things that are specific to particular types of data stores will be available as extensions that are included as part of the provider. For example, the concept of a model builder that allows you to configure your model will be part of the core framework. However, the ability to configure things such as cascade delete on a foreign key constraint will be included as extensions in the relational database provider.

In the TechEd session you can see a demo of EF7 being used to access Azure Table Storage starting at 56:45.

Challenges

As we look at what we want to achieve in EF7 we’ve had to take a realistic look at our current code base. While it has served us well and allowed us to release some solid versions of EF in recent times, it is not really setup to achieve what we want to in EF7.

The EF code base has a long history, going back to the WinFS days, with parts of the code base being 10+ years old. The current code base makes extensive use of older APIs and design patterns. Many of the APIs that EF uses heavily are not available on the new platforms we want to target. In addition, the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.

When Entity Framework began life, it’s charter was more to do with the Entity Data Model vision rather than being a best-of-breed O/RM. As a result, there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.

While using less resources is desirable on all platforms it becomes more prominent on devices as they typically have fewer resources than desktop and server machines. These concerns were not a driving factor when EF was designed and implemented. The current resource usage of EF hinders its ability to be a good data access offering on devices. We’ve done some investigation on lowering resource usage and found it to require architectural changes that require a very large amount of work. As we move toward cloud computing, low resource usage is also desirable as it allows greater density of applications on servers – and is often directly tied to billing.

EF7 is Lightweight and Extensible

EF7 will be a lightweight and extensible version of Entity Framework that just pulls forward the commonly used features. In addition, we’ll be able to include some commonly requested features that would have been difficult to implement in the existing code base, but can be included from the start in EF7.

We’ll be keeping the same patterns and concepts that you are used to in Entity Framework, except where there is a compelling reason to change them. You’ll see the same DbContext/DbSet based API but it will be built over building block components that are easy to replace or extend as needed – the same pattern we’ve used for some of the isolated components we’ve added in recent EF releases.

What About My EF6 Apps

We will still continue to invest in EF6 while we work to make EF7 have better feature parity with EF6. In fact, we implemented the EF6.1 and EF6.1.1 releases while working on the EF7 code base.

Upgrade from EF6 to EF7 is a key scenario for us, both in terms of existing code and existing knowledge. We’ll be keeping the same concepts and patterns wherever it makes sense. The upgrade to EF7 will require some changes to your code. Our aim is that code that uses the core functionality of the DbContext API will upgrade easily, code that makes use of the lower level APIs in EF may require more complicated changes.

Get Involved

It’s early days, but we are underway with the EF7 implementation. We’re developing in the EntityFramework GitHub repository and have nightly builds available. We aren’t able to accept contributions just yet, but we will in the near future.

If you want to try out the nightly builds, just bear in mind that this is pre-alpha code and there is a lot of functionality that is partially implemented or still to be added. Visit our documentation on GitHub for more information on getting started with nightly builds.

We’ll keep you updated with more details on EF7 and the features we are implementing over the coming months.

Comments

Anonymous
May 19, 2014
Gee, I just started learning the Entity Framework and then I learn Model First and Database First will be dropped and ObjectContext won't be there in EF7. At least I know what to focus on now : ).
Anonymous
May 19, 2014
>We are explicitly not trying to build an abstraction layer that hides the type of data store you are targeting. Brilliant. I'm glad to see this approach start to die off.
Anonymous
May 19, 2014
This seems like a reasonable decision to make. I do worry about the ability to migrate EF 6.1 apps. Our company mainly uses DbContext, but there were occasional things the DbContext API didn't seem to do, which we use ObjectContext for. For example, using the metadata workspace in ObjectContext, we sometimes look up mappings to generate SQL for scenarios that EF does not natively handle. In v6.1 this was made significantly easier, but it sounds like it would go away for 7. If EF7 is very roughly a re-implemented and modernized DbContext, is the intention over time (e.g. an EF7.1 or 8) to provide some of the capabilities of ObjectContext, but in a more modern way? Another way of looking at this: one could think of any of the "advanced" EF 6.1 functionality in two buckets: things which have a valid place in a modern O/R solution, but are more advanced or uncommon scenarios that may not make the cut for the first pass that is EF7. Second, things which are truly legacy and don't have much value. My hope would be that the former would eventually find their way into the new EF, even if the APIs themselves don't look exactly the same.
Anonymous
May 19, 2014
@James S - Yes, we'll absolutely be providing some of the functionality you had to drop down to ObjectContext for, but just implemented in a more modern and better designed way. For example, working out what table an entity maps to is very hard via MetadataWorkspace, but in the current EF7 code base it looks like this: context.Model.GetEntityType(typeof(Blog)).StorageName Of course, the exact API may change, but the idea being that you can achieve the same thing in a simpler and more intuitive way.
Anonymous
May 19, 2014
Thanks for the update. I like the New platforms. Not so sure about the support for non relational data stores.. but I'll keep an open mind!
Anonymous
May 19, 2014
Maybe it's time to think about all of us that still use L2S because 'it just works' without all that complexity. Fom what I've read it looks like EF7 goes in that direction, so maybe you could try and provide an upgrade path for us ?
Anonymous
May 19, 2014
How about getting ideas from NHibernate ? (actually that's what you should have done from the beginning!)
Anonymous
May 19, 2014
In your post, the „Entity Data Model vision“ is mentioned in a rather negative context, whereas it’s the ONLY feature that remarkable distinguishes EF from other ORMs. Given the fact EF is relative young and pretty buggy (and is definitely going to be much more buggier as further platforms and DBMS get “supported”), this solely feature (combined with ESQL) can made someone to choose EF over some other EDM. Well, LINQ is nice but very limited (will EVER be); you won’t also construct LINQ expressions on the fly if you need dynamic queries (at least if you’re sane). So, EDM+ESQL remain the only choice for a wide class of analytical applications letting user construct their own queries against a DSL-model they are familiar with. I wonder how you’re going to achieve this using simplistic DbContext approach. Do you really want us to handcraft and maintain hundreds of POCO classes just for to use their metadata? We all do realize that this “cross-platform hype” is in fact nothing more as a hype and is driven politically and so on. As well as that EF team can’t really change or resist it (I hope you wish to), but if you drop EDM or/and ESQL, you’ll definitely have one dedicated customer less. Maybe we are the only customer around the world using EDM and ESQL nowadays, but these are only two parts, which really work well, with no hidden surprises, like hard-coded provider names in Code-First implementation (I wonder if further DBMS are going to be “supported” this way either). So if you really cannot stop delivering bells and whistles and concentrate on the homework, at least don’t drop or change the basis that works.
Anonymous
May 19, 2014
What I don’t understand either, is why do you want to call it EF7 (in fact I do understand it of course, but simply can’t accept). Just make a dedicated branch for Mono, let it some considerable time to be re-designed and to grow rapidly, without spending 80% of the time for backward compatibility. Than, if you still have to, estimate the outcomes and weight them against a new “political situation” and decide deliberately if it’s worth and still need to be merged into the main branch. Or even make it a new main branch if you please. It is how we develop software nowadays to minimize the risks. Instead, by calling it EF7 you are going to stake everything on a black horse called “Mono vNext”, scattering efforts on re-design the whole things, yet (assumable) providing a backward compatibility and (definitely) leaving your homework undone for years.
Anonymous
May 19, 2014
I'm interested in why you guys are moving the project from CodePlex to Github. I'd think it would be easier to get features you want in the site in an MS-owned website vs Github.
Anonymous
May 19, 2014
@Rowan Miller -- That's great to hear. It will no doubt be painful for some to upgrade, but when all is said and done and the new EF7 stabilizes, I think it will be for the best.
Anonymous
May 20, 2014
I'm just glad that EF will finally target Windows Phone. I've been working on two apps (one Windows Phone and one Windows desktop) and right now, I can't use the nice EF setup I have on Windows Phone. With EF7, I'm expecting that I will. This is great news! I want to have one code base for the underlying database model and looks like EF7 will help me get there.
Anonymous
May 20, 2014
@Clement – We’re definitely striving to build things in such a way that allowing other data stores doesn’t detract from the relational experience. Even if you only use relational, we still want EF7 to be a great release for you. @Jens Samson – Agreed, some of the driving principles from L2S are definitely present in EF7 (and also drove the DbContext API etc. in recent EF releases). Providing some clear guidance on migrating is a great idea as it should be much simpler than moving to EF in the past. @Onur – I think in general there are a lot of generally accepted patterns etc. for data access (and frameworks in general) that it makes sense to follow. We’ve done that with the recent releases of EF, but now in EF7 we get the opportunity to pull those principles/patterns into the core parts of the framework. I agree that EF hasn’t always done a good job of embracing these things – hence the ‘Challenges’ section of this blog post. @MgSm88 – At the moment the use of GitHub is just about developing in the same place that ASP.NET vNext is being built (so that we can share infrastructure etc.) and about developing in a place that is already in heavy use by the OSS community at large. @TTRoadHog – You can definitely share code between platforms as it will be the same EF code running in all places. I just want to be clear that at the moment you won’t be able to connect to a remote SQL Server database directly from a Windows Phone/Store application. This isn’t a restriction we are putting into EF itself, it’s a limitation enforced by the sandbox those apps run in.
Anonymous
May 20, 2014
@Dennis – A few thoughts based on your comments. I realize I’m probably not going to change your mind on the EF7 vision, but wanted to share our thinking anyway :).

While EF7 won’t be built on the EDM infrastructure that earlier releases are, it will still have a number of the same concepts (relationships, entities, etc.), just implemented in a way that are optimized for an O/RM.
Dynamic querying is definitely a real scenario, EDM and eSQL isn’t necessarily the easiest/best way to achieve it though.
You mentioned having to handcraft classes, EF7 will still contain the ability to reverse engineer a code-based model from an existing database (same as EF6 does today). It’s just the xml-based EDMX format that we’re not planning to pull forwards.
I don’t think that cross-platform is just hype. Being able to store data locally on a device is a real scenario and we have seen many folks asking us to enable EF on Windows Phone for some time now.
You mentioned “hard-coded provider names in Code-First implementation” and we totally agree that things like this are an issue. Needing to do things like that stem from the limitations of the underlying code base that we are trying to build these features on top of. These are things we will be removing in EF7.
Mono isn’t necessarily a key focus for us, we want to build the next version of EF to be easier to use in more places. Given we want to do that, it just makes sense for us to make it portable and get all those platforms ‘for free’.

Anonymous
May 20, 2014
Reducing the amount of EF code between our server side application and the SQL database is nice. ORM benefits most in the early development phase and increases in cost 2-3+ years after the first production release.
Anonymous
May 20, 2014
The comment has been removed
Anonymous
May 20, 2014
The demise of ModelFirst is a big concern for me... and most people that develop enterprise desktop applications. For us, is silly to use CodeFirst, in the first place, because in most environments you, as user, has no rights for modifying a database's DDL. And that's a sound limitation, by the way. It's simply stupid having all terminals starting their day by concurrently checking pending migrations. The thing that worries me the more is that I can perceived the same pattern that led Microsoft to the Windows 8.0 fiasco: neglecting their loyal base of enterprise developers.
Anonymous
May 21, 2014
Rowan, are you saying that I won't be able to access an Azure SQL Database or Table Storage from my Windows Phone using EF7? I well understand the value in having a local (on the phone) database storage option but for larger databases, I want to be able to access an Azure SQL Database that's remote. I thought that was the paradigm Microsoft has been moving to lately.
Anonymous
May 21, 2014
@Ian Marteens – Code First can be a confusing name (our bad), perhaps ‘code-based modelling’ is a better term. Code First isn’t just about defining your model in code and having it create a database for you – although that is one of the supported scenarios. In the same way the EF Designer let you reverse engineer from the database (Database First) or create a model then generate the database from it (Model First), you can reverse engineer a code-based model from a database or create the model and generate/update the database using migrations (both these patterns are already supported in EF6 today). We totally agree that having EF be chatty with the database on startup and try to do a bunch of magic isn’t a good thing. The database initialization stuff definitely falls under the ‘Sensible Defaults, Less Magic’ principle and our plan is to not do anything special by default inEF7. We’ll have all the APIs available to check database existence, check pending migrations, apply migrations, etc. and it will be up to app developers to opt in to what (if any) of that they want to do on app start. BTW we also want to overhaul our deployment story so that applying migrations during deployment (rather than app start) is the default process. Code First definitely has some rough edges for enterprise/large apps. One of those was the substandard tooling for reverse engineering a model from a database – but we gave it the same wizard as the EF Designer in EF6.1. Another big one is that migrations has issues in team environments, and we are already working on a solution for that in EF7. Code First also has a lot to offer enterprise/larger applications though and we are seeing a number of our larger customers chose to adopt Code First for this reason. Having isolated code files makes code reviews and source control merges a lot easier than one monolithic xml file – especially when you have a large model. Because the model is calculated from code it is easier to have the model adapt dynamically at runtime (i.e. add configurable fields etc.) which is often a core requirement of enterprise apps. Dynamic models are ‘easier’ in Code First in EF6 but we’re also introducing the concept of ‘shadow state’ in EF7 where you can store extra info for an entity that doesn’t have a matching property on the class – this will make dynamic models much easier. These are just a couple of examples. If you have other scenarios that are important to your enterprise apps that you want us to make sure have solid support in EF7 (even if they are really difficult in EF6) then please let us know. We definitely need the help of our customers to make EF7 a great release for all different types of apps. Enterprise is definitely a key scenario for us.
Anonymous
May 21, 2014
@TTRoadHog – What data stores can be accessed from the Phone depend on the restrictions of the Phone platform itself and also the availability of the data access APIs to connect to the store. Azure Table Storage should be fine because it uses http to talk to the data store and the table storage APIs (which the EF provider uses) are available for the phone platform – though they aren’t available for the wpa81 target platform just yet. SQL Server is a different story because it doesn’t use http and the platform restricts the ability to communicate over the needed protocols. Of course, this may change in the future – but that decision isn’t one our team gets to make in isolation :).
Anonymous
May 21, 2014
The comment has been removed
Anonymous
May 21, 2014
The comment has been removed
Anonymous
May 21, 2014
@Dennis – Gotcha, yes I was missing that you don’t have any CLR types at all (this isn’t a common scenario that we see folks using). This will be supported in EF7, but whether it makes sense to move or continue using EDM/eSQL is a decision that you’ll need to make based on what works best for you. We’ll be continuing EF6.x updates, so there is no ‘mandate’ to move. Just in case you were interested. This will be possible in EF7 via the concept of shadow state (data that doesn’t have a corresponding CLR type and/or property). Normally this would only be used for some aspects of your model, but it could also be used for your entire model. To support this we’ll also have some way to construct queries that aren’t tied to CLR types, we have various ideas about how to do this, but haven’t decided on specifics as yet. Of course, the model construction is done in code, but that could always be driven by some external configuration source (file, database, etc.).
Anonymous
May 22, 2014
@Onur - Good feedback, thanks for taking the time to write it up! Reducing restrictions on the shape your domain entities is definitely a scenario we want to tackle in EF7.
Anonymous
May 22, 2014
@Dennis, Others: Model First & Database first are aspects more suitable for the tooling you use. E.g. with the right tooling (designer) you can do model first or database first and create the mappings and classes (if you want) for the O/R mapper of choice. In v1-4,5, and 6 EF supported EDMX based mappings and classes, but also code-first (fluent api) mappings and classes. With the right designer for Entity Framework you can proceed with using Model first & Database first and generate EDMX mapping files and classes for EF 1-6 and Code first mappings for EF 6 and higher. So with the right tooling it's not going to change. EF 7 focuses on code first only, but if you use a designer which offers you a Model first or Database first experience and generates the code first mappings for you and the entity classes (if you want to). I.o.w.: typing them in yourself by hand (why would anyone do that is beyond me, but hey, some people love to type) isn't the only way to get code first mappings ;) With 'the right tooling' I am referring to commercial products, not free tools.
Anonymous
May 23, 2014
@Frans - Good pitch for commercial tools. However, keep in mind that there are also good free tools out there that add new capabilities to the existing EF/EDMX designer. As you probably know, my toolset for EF (and L2S) are now free (although used to be commercial). There is a demo video of combined Model First and Database First here: www.youtube.com/watch , and the tools used in that video can be downloaded from https://huagati.com/edmxtools
Anonymous
May 23, 2014
@Frans - that said: your tools for EF and other ORMs ( http://www.llblgen.com ) are pretty awesome too! :)
Anonymous
May 23, 2014
I think this is a good, required step in the right direction, just kepp in mind that the more sophisticated features and the undergrowth of EF team supported extensions to EF6.1 are now making EF a viable alternative to nHibernate, and I think it is important to maintain the same level of features in EF7. Also hoping that creating a provider for another relational store will be simpler than with EF6. Looking forward to the coming months of commits, and hope that VS tooling for the new json project format will come soon, and assume you will also be able to open for pull requests at some stage.
Anonymous
May 23, 2014
Are you still going to have a reverse engineering tool for existing databases? It would be nice if the existing one could be sped up some. Although I think the issue of slowness I ran into may have had to do with the MySQL driver that I'm using. Context initialization for large models still needs a lot of improvement. And something really needs to be done to address bulk operations. I would rather see a focus on this than supporting non-SQL data sources myself.
Anonymous
May 23, 2014
The only reason we don't use code first at my job is because it don't support Upgrade Model from Db. You need to select all tables again and generate from zero losing all customization. Will you support it in EF7? Or will be a really pain to get changes from db. We also need a upgrade tool to convert EDMX to code
Anonymous
May 27, 2014
The comment has been removed
Anonymous
May 28, 2014
can you tell us a release date?! anything, even the quarter of the year!
Anonymous
May 29, 2014
Any plans for adding full-text search support for SQL Server at least? It would be great if LIKE '%x%' searches could somehow be sped up using normal SQL indexes. I guess you need a full-text index to do that efficiently (I.e. substring searches).
Anonymous
June 02, 2014
The comment has been removed
Anonymous
June 02, 2014
@Jon - We're not really sure what full-text search will look like in EF7 yet. In the initial RTM it may be that you need to drop down to raw SQL (the same as you do in EF6). We are making the query pipeline quite a bit more extensible in EF7, so it may be that it's easy to extend things to use provider specific features, or if it's more complicated we may provider some helpers in the SQL Server provider for them. Sorry not to have much more info at this stage, we just haven't padded out all the design as yet.
Anonymous
June 23, 2014
The comment has been removed
Anonymous
June 26, 2014
@Kenneth Brubaker - We haven't really designed the reverse engineer process yet, but yes, we'll make it extensible like the existing EF6 process (possibly still using T4). My comment about not supporting updates was more about incremental updates to the model without overwriting everything. We want to enable that with Code First, but it probably won't be there for the initial RTM of EF7.
Anonymous
June 27, 2014
Will there be any support for Soft Deletes in EF7 or later on? It was a nice demo you showed but maybe not something everyone should try to implement themselves since it's a bit complicated.
Anonymous
July 02, 2014
@Johan Ohlin - It's unlikely we'd have native soft delete support in the initial RTM of EF7. That said, in EF7 it will be much easier to implement a similar solution to the demo you mentioned that it was in EF6. A lot of the factoring/architecture work we are doing in EF7 will make it a lot easier/quicker to implement feature like soft deletes in following releases.
Anonymous
July 07, 2014
Nice to see a newer version of EF is coming out. Looking forward to use this. Also it would be nice if EF team can provide better documentation of its features with tutorials like in http://asp.net. Keep up the good work
Anonymous
July 08, 2014
@Nipuna - Better docs is definitely something we'll be doing in EF7. We have some decent content but it's hard to navigate/find. We also want to enable community contributions to docs as well.
Anonymous
July 23, 2014
The comment has been removed
Anonymous
July 27, 2014
Any sight on EF 'native' FILESTREAM (and the like) support in EF7?
Anonymous
July 29, 2014
Does anyone know if startup time is expected to be faster in EF 7? I have a model with about 1,300 entities in it and it is currently taking about a minute for the DbContext to initialize. I'm hoping this will be improved in 7. Also, I would like to see 7 use prepared statements for insert/update operations. I would also like to see a Clear() method to allow clearing the DbContext. This is needed for applications that perform bulk updates which isn't really possible in EF 6. It is just too slow. I know ORMs aren't really designed for this, but, I have a feeling that EF still lags far behind Hibernate in this regard.
Anonymous
July 29, 2014
@Otto T

In EF7 we've also introduced the ability to have 'shadow state' properties, which are properties that are considered part of an entity but aren't present in the actual CLR type. We want to light up the ability to query based on these properties too, but given they aren't in the CLR types, strongly typed LINQ operators based on CLR types/properties won't work for them either. We haven't designed what it will look like yet, but the string based approach we use for them will probably be what we use for dynamic queries too.
Yes, we'll allow customization of the code that gets generated. Probably similar to how we allow customization of reverse engineered Code First models in EF6 - msdn.microsoft.com/.../dn753860.

Anonymous
July 29, 2014
@Jon – Performance is a big priority for us in EF7 and we expect to be able to make some big improvements. Regarding a Clear() method, is there a reason this would be better than just creating a new instance of the context?
Anonymous
July 29, 2014
@Barry – No plans explicitly around FILESTREAM in the first release of EF7. We are building things to be a lot more extensible to allow provider specific types to be handled much more easily. We may not have all the pieces to handle arbitrary types in the initial RTM of EF7, but we are building out the architecture with this in mind.
Anonymous
July 30, 2014
Hi @Rowan ... I am trying to make a interception for insert command using the new EF 6.1 capabilities. This is my code: http://pastebin.com/PBH9ts6t NOTE: In region closure you can view the SQL sentence that i want to implement as. The error is: Can't convert an object of type 'System.Data.Entity.Core.Common.CommandTrees.DbScanExpression' to type 'System.Data.Entity.Core.Common.CommandTrees.DbPropertyExpression'. NOTE: I translate the error message manually, maybe in english is not exact this. I'm trying this code and many similar sentences, any of which doesn't work yet for me :( I have a "Domain" entity that contain a "HierarchicalIdPath" column that represent the path (as string) to its hierarchical route. This field is very usefull for check childs or parents and more. I want to populate this column automatically in the interception. How is wrong? Is possible do it by this way? Thanks, a greeting.
Anonymous
August 03, 2014
Hi @Rowan, can you tell us what features of the current EF in the first version of EF7 disappear? The following items are known to me:

Model First
Database First (with EDM designer)
ObjectContext, EntityObject, ...
EDM
eSQL
Complex Types Can we expect the following Features:
Relationship (one-to-many, one-to-zero-or-one, one-to-one, many-to-many)
Self referencing associations
Inheritance (TPT, TPC, TPH) An important point for us is that it's possible to create queries dynamically, which is not quite possible with LINQ.

Anonymous
August 04, 2014
@Oscar Jimenez - Any chance you could use the 'Contact' link (red square button at the upper right of this page) to send me some a project that demonstrates the issue. We'd really need to dig into some running code to work this one out.
Anonymous
August 04, 2014
Please note that 'database Sequence' until SQL Server 2012 is available: github.com/.../Entity-Framework-Design-Meeting-Notes---July-31,-2014 For older SQL Server it should be possible to use Identity.
Anonymous
August 05, 2014
A feature that I would love to see would be multi-vendor database support from the same model and generation of interfaces for the entities. With interfaces I would be able to load the model I need to use and then multi-vendor support from the same model would not be an issue. I don't know how well this fits with the current EF7 roadmap but it is an important feature for our uses.
Anonymous
August 07, 2014
@dgxhubbard - By multi-vendor support do you mean the ability to target different database engines with the same model? That's possible today in EF6.x with code-based models (it's technically possible with the EF Designer too... but not very easy).
Anonymous
August 07, 2014
@Marco - Configuring a column as identity will still be easy in EF7, we're just looking at making the default be sequences instead of identity.
Anonymous
August 07, 2014
@Marco – While EDM/MetadataWorkspace is going away there will obviously be a replacement structure to hold the metadata. This will be public… and significantly easier to use :). Relationships will be available (in the various flavors you mentioned). We won’t have all the inheritance patterns supported in the initial RTM (we may not have any support in the initial RTM but we definitely plan to support inheritance in EF7) – it’s not clear whether we will support all the inheritance patterns from EF6 going forwards or make things a little more restrictive. Dynamic query will be possible via a new API which will also allow you to query based on properties in shadow state (a new feature in EF7 where you can have additional properties that aren’t in your CLR classes).
Anonymous
August 07, 2014
The comment has been removed
Anonymous
August 12, 2014
The comment has been removed
Anonymous
August 12, 2014
This is really good to know that Microsoft is investing heavily on EF and I am very sure once day EF will be top choice. But I think there is a long way to go , functionality such as formula properties still need to be part of EF
Anonymous
August 13, 2014
@vinod shalgar - Could you elaborate on the scenario you have when you mention 'formula properties'?
Anonymous
August 15, 2014
Good the edmx and extra mapping layer is going away but why ditch the designer? Database first model design is not very clean. Now the difficult mapping is going away 1 to 1 automatic sync between code and a designer with extra t4 support for your own generations is a serious option. Please give this some thought as most people like a visual overview for complex models. We have build hundreds of successful apps with ef, objectcontext, t4 generation and multiple models. For us the only things missing were unique key handling, genuine batch updates and deletes and easier updatable views. So I hope your focus handles this. Good to make it lean but please do not forget the enterprise developer!
Anonymous
August 16, 2014
I am talking about the capability of NHibernate where can specify formula eg <property name="Deposit" formula="Rent * 12"/>
Anonymous
August 18, 2014
I am very interesting on the feature taht allows to filter related entities when is loaded with the Include method. Will EF7 allow this? Thanks.
Anonymous
August 18, 2014
The comment has been removed
Anonymous
August 21, 2014
can we connect to some of the file source like a xml file or else excel files in EF 7.0
Anonymous
August 21, 2014
@Rowan Miller, I guess vinod shalgar would like to query this property and you can't query a non mapped CLR property (orderby, where, ...) as it's not an expression. He is asking for calculated properties support. Do you plan mapping to private fields for EF7 ? entityframework.codeplex.com/wikipage
Anonymous
August 22, 2014
@vimmal - It's a matter of having a provider. It would certainly be possible to write one for CSV files etc. Our team isn't planning to write one (at least for the initial RTM), we will be providing guidance on how to write provider though.
Anonymous
August 22, 2014
@Guillaume - Query makes sense for the formula properties. We're unlikely to support it in the initial RTM, but as with most features folks are asking for, it's something that will be a lot easier for us to implement (or someone in the community to contribute) on the EF7 code base. Regarding mapping to fields, we already support having EF7 map to the field that backs a private property (to avoid triggering login in the getter/setter). We do plan to enable mapping to fields but probably not in the initial RTM.
Anonymous
August 26, 2014
I am just beginning with EF 6.1. The tutorials that I've viewed indicate that Model-First is the preferable method to design if you don't have a DB to start with. It is certainly helpful for a beginner. Just putting in my 2 cents.
Anonymous
August 27, 2014
Any chance 7 will use prepared commands for inserts/updates? Or are any other optimizations planned for faster bulk updates? Something really needs to be done to improve batch update speed in EF. I hope it makes it into 7. I know ORMs are historically not good at this scenario, but, I think if you compare EF to NHibernate, Hibernate, JPA, etc. you will find that EF is significantly worse. I'm really hoping that startup time is improved as well. It takes about 15 seconds to initialize a model that I have of an existing database with 500 tables. If I included all the tables in the database, it would be 1,300 and the startup time would be more like a minute. Admittedly, the database I'm working with is poorly designed and could have probably been done with fewer tables, but, EF startup slowness makes it unusable if I try including all the tables in the model.
Anonymous
August 28, 2014
The comment has been removed
Anonymous
August 28, 2014
A blog post on the newly deployed batch CUD operations (as updated on uservoice) would be appreciated once you feel ready to sing it's praises! Looking forward to that one.
Anonymous
September 03, 2014
@Michael Chean - Here is an overview of the different options, including creating a code or designer based model from an existing database - msdn.microsoft.com/.../jj590134.
Anonymous
September 03, 2014
@Mark Foley - Will do, there is already a simple implementation of batching up commands checked in to the EF7 code base.
Anonymous
September 05, 2014
One thing that I would like to see in EF 7 that I almost forgot about is for the ForeignKeyAttribute class to be enhanced to support foreign keys that use more than one column. As far as I know, you have to use the fluent API in this case presently. Personally, I don't like concatenated keys, but, I'm working with a legacy database that I don't have control over the schema.
Anonymous
September 08, 2014
Are there any plans to support read-write access for sql_variant type in any future version of EF?
Anonymous
September 08, 2014
@Jon - We intentionally try to keep the data annotations simpler, and require that you drop down to the fluent API for many of the more complex mappings. Honestly, the relationship attributes are already pretty complicated so I don't think we'll be adding additional concepts to them.
Anonymous
September 08, 2014
@Matt - We don't have plans for native support. That said, one of the goals in EF7 is to make type mapping/conversion much more flexible. We're not going to have all this in place for the initial RTM of EF7, but we are laying a lot of ground work. I can't make specific promises (since we haven't designed a lot of it yet), but scenarios like this should be a lot more feasible in EF7.
Anonymous
September 08, 2014
Do you still plan to provide better support for working with disconnected entities as per work item number 864 on CodePlex?
Anonymous
September 09, 2014
@David R - We're laying some ground work for better support but I don't think we'll get as far as full etag support etc. for the initial RTM.
Anonymous
September 14, 2014
Just for clarification, will there still be a way to reverse engineer from an existing SQL Service database to create the classes needed for code first?
Anonymous
September 15, 2014
@HS Gurvey - Yes, similar to the tooling that is available today in EF6.1.
Anonymous
September 18, 2014
We now have no more understanding of the policy for Microsoft. We have run stable after many bugs finally our application. We have over $ 50,000 damage. It runs with ObjectContext, because it was recommended by MS! And now comes another change of direction. ObjectContext is dead. Here you can not even change the database provider tidy yes! It runs not even now anything about. How about bringing a program finished?
Anonymous
September 18, 2014
@j.nord - EF6 will still be a supported release so you can continue using ObjectContext and still get support. We'll also continue updates to EF6 as we work on EF7 - in fact we've already been doing this as the 6.1, 6.1.1 and 6.1.2 releases were all done while we were actively working on EF7 too. Taking breaking changes to our product isn't something we take lightly, but at this stage we think it's the right thing to do to keep the stack moving forwards and allow us to provide the features and functionality that customers are asking for.
Anonymous
September 18, 2014
Here is a good discussions about the problem about convert to dbcontext: entityframework.codeplex.com/.../540333 There are many problems they must solve!
Anonymous
September 29, 2014
I had to perform a downgrade from EF 6.1.2 to EF 5.0.0 because the initial data model loading on the first query was taking between 42-55 seconds, the model have 550+ tables. However, this situation not occurs in EF5. We will see some changes related to this in EF7?
Anonymous
September 29, 2014
Hi Diego, could you file an issue so that we can investigate the performance regression you mentioned in the beta of EF 6.1.2? entityframework.codeplex.com/.../Create. One of the reasons we do beta's is to catch issues like this so that we can fix them for RTM. Be sure to include code (or even better, a complete project) that demonstrates the issue. As for your question: EF7 is a new codebase. Certain performance characteristics will be similar to previous versions of Entity Framework, but we'll need to analyze the actual cause of the issue you're experiencing in order to determine whether EF7 will behave differently or not. In any case, performance regressions in EF 6 are still highly important for us to analyze and fix. We appreciate your help.
Anonymous
October 01, 2014
Hi David, I've created the work item reporting the issue as suggested me. entityframework.codeplex.com/.../2532 Let me know anything else. Thanks for support.
Anonymous
October 03, 2014
Why not take different name for this new ORM? If it will not have 60% of EF 6 features like metadata and even inheritance it will not be EF.
Anonymous
October 07, 2014
We need Database First for existing database scenario, what is the point to take it out? If Microsoft want to have more adepts. I wish also to see SQL full text search capability with different language dictionary. EF7 need to concentrate on delivering performance. Not just fast coding for fast delivery and not suitable for large database.
Anonymous
October 07, 2014
Upon checking out vNext / MVC6 / EF7, I noticed immediately that the LinqKit and System.Linq.Dynamic areas of functionality seem to be unavailable. I'm thinking of the use dynamic orderby and also predicatebuilder for dynamic querying. So the question: Will EF7 finally include the native ability to dynamically orderby and also employ some kind of predicatebuilder mechanism?
Anonymous
October 08, 2014
@Oleg - We have spent a lot of time discussing branding/naming etc. While EF7 has some significant changes from EF6.x we ultimately decided it is more "the next version of EF" than it is "a new thing". Obviously that is somewhat subjective and some folks will disagree (in fact there are even varying opinions within our team). Regarding the metadata question, there will still be metadata, it's just the API will look like what we (and our customers) have always wished the metadata API would look like. Had it been more practical, we would have refactored the existing metadata API long ago :). Inheritance may not be there by the initial release, but we think it is a critical feature of an O/RM, so we'll be adding it ASAP (hopefully by our initial release). One thing to point out, is that we are very aware that not everyone is going to be able to use the first release of EF7 to build every application because it's not going to do everything folks need from a O/RM. That's one of the main reasons behind continuing EF6.x development beyond the time period we normally would when we complete a new major release. What we want to do is implement a good set of features that work well for a lot of applications whilst also building out a solid core framework that will allow us to do all those features that were really hard to do on the EF6.x code base (flexible type mapping/conversion, batching of CUD statements, partial client side evaluation of LINQ queries, and many more). Hope that helps provide some insight :).
Anonymous
October 08, 2014
@Lap – We aren’t retiring the ability to reverse engineer a model from a database, we’re just retiring the XML-based EDMX format. In EF7 all models will be stored as code – but that code can either be reverse engineered from an existing database, hand coded to map to an existing database, or used to create a database. Full text search probably won’t have baked in support for the initial release, but that is exactly the kind of thing that will be easier to support on EF7 than in past versions of EF. Performance is also a key focus of EF7 (and in fact one of the driving motivations for many of the changes/decisions in EF7).
Anonymous
October 09, 2014
To be honest , you have not been successful to invent something more powerful than ADO.NET + Stored Procedures.It's nice in the theory , but when you gonna start a big app from scratch , we do prefer to start by ADO.NET again even in a service layer or something like WCF or WebAPI 2 , we like to use ADO.NET as a core of the service or ... !.
Anonymous
October 09, 2014
@Mark Brookes – LinqKit should continue to work with EF7, we opened a work item to verify this on our end github.com/.../833. Note that LinqKit currently only targets full .NET, so like many other libraries it would need to support CoreCLR to used in ASP.NET vNext projects that target CoreCLR (but will work fine in ones that target the full framework). We may pull some things into EF itself, but we haven’t spent a lot of time digging into that area yet.
Anonymous
October 09, 2014
@alikolahdoozan - Raw ADO.NET is still very much a valid option for folks who don't want the abstraction of an O/RM. If that is working for you then it's a perfectly valid option for you continue using.
Anonymous
October 09, 2014
@Rowan Miller : First of all , thanks for the answer.In the second, I should mention , we have our own custom ORM to generate the layers and classes , but everything is based on ADO.NET and SPS.
Anonymous
October 14, 2014
Will all Xamarin platforms be supported like iOS or should I use something like SQLite-NET? Thanks.
Anonymous
October 17, 2014
@Jake - Yes that is what we are working towards. There are a few nuances we need to work thru as what's actually in the various frameworks is different, so they aren't supported yet, but that is what we are working towards.
Anonymous
October 20, 2014
So can we use EF7 + CoreCLR for a basic Crud app using SQL Server? Or does this still require the full CLR to run against for vNext?
Anonymous
October 21, 2014
@Jacob G. Rillema - Yes, that scenario works on Core CLR for ASP.NET vNext now.
Anonymous
October 23, 2014
I've read through all the comments and find this to be a great discussion. Illuminates areas in EF I have never thought about. The 'post-mortem' remarks on EDMX don't seem to address a question I have though. Will the 'dynamic data' web project go the way of the dinosaur? This has been a very handy way of creating an interface for data administration of database. (not schema) Second question I have is whether the difficulties in using code first data migrations when a database is used by multiple projects will be addressed? I've had trouble with keeping two or more projects 'in sync' using code first to address the same database. Migrations are great help, but frequently the 'not initial' projects have trouble with 'automatic' syncing of the data model on application initialization.
Anonymous
October 27, 2014
@DevDells - Honestly, I'm not sure if we'll create a dynamic data provider 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. Regarding migrations, the issues you saw probably stemmed from all the automatic checking that EF did when it started up. The main model you were using to drive the database was probably happy, but the secondary ones that just consumed the database (rather than maintaining the schema) would sometimes fail the compatibility checks. If that's the case, then we've got rid of all the magic startup logic in EF7 so you won't see this issue any more.
Anonymous
October 28, 2014
Hi! I have a question about enabling new data stores. Would EF7 be a good fit for a document/NoSQL database, something like MongoDB? Thank you!
Anonymous
October 29, 2014
@Mike - Yes, for certain use cases. In some ways this would be similar to our Azure Table Storage provider where you would generally include properties in your CLR classes for 'properties' that are common across most/all entries in the data store. Additional data from the store (which may vary greatly between entries) is stored in 'shadow state'. Shadow state is a new feature in EF7 that can keep track of additional data that isn't present in your CLR classes. Of course, in some scenarios you are going to need this data in your CLR class (serialization etc.) so we want to enable patterns like having a property bag on your CLR class for additional data.
Anonymous
November 18, 2014
What about WCF RIA Services it'll look for EDMX file ( Technically Tool that generates code for us ). We need to generate classes for our self.
Anonymous
November 22, 2014

When EF will allow to retrieve fresh data from database into global context variable? I intended to create multi-user application which supposed to immediately see the changes done by other users. EF doesn't retrieve new data from database, if context variable is global - it just continues to use its Local cache. I hear everywhere that I should use only local context variable and dispose it immediately. But what about data binding? If I retrieve data, bind to DataGrid and dispose context, then I wouldn't be able to edit and save data. This is really frustrating. Wish there would be some method which would allow to get fresh data from database.
Will EF7 support EntityTypeConfigurtion class?

Anonymous
November 25, 2014
The comment has been removed
Anonymous
November 25, 2014
@Johny - You can use the DbContext.Entry(object).Reload() to get fresh data for an individual entity. You could also look at dropping down to ObjectContext and using MergeOption to merge in changes from the database. In EF7 you will be able to use a pattern like EntityTypeConfiguration, but it probably won't be that class exactly.
Anonymous
November 30, 2014
Is new version going to address the issues described here? enterprisecraftsmanship.com/.../entity-framework-6-7-vs-nhibernate-4-ddd-perspective
Anonymous
December 01, 2014
@Linloil - From that post: #1 - EF7 will address this but probably not in the initial release. Here is the work item tracking the work - github.com/.../333. #2 - This one is a false assertion, EF does not require you to have FK properties in your objects (true from the first release of EF) #3 - This is on our backlog but probably won't make it into the initial release of EF7 (but we've laid a lot of ground work to enable it in the future) - github.com/.../240. #4 - Key generators are already supported in EF7.
Anonymous
December 01, 2014
@Rowan Miller #2 - Agreed. But still there are two problems:

Accessing Id property of the related entity triggers full object load, although that Id is already in memory.
EF emphasize developers using Ids instead of just related entity reference. Partly, because it's the default way of binding related entities, partly because all the examples use this approach and partly because of (1). I'm taking into account situation with EF code first only. Situation with non code first version is much worst in the DDD perspective.

Anonymous
December 02, 2014
@Rowan Miller Added case #5: Working with cached objects enterprisecraftsmanship.com/.../entity-framework-6-7-vs-nhibernate-4-ddd-perspective Is this issue going to be addressed?
Anonymous
December 02, 2014
@Linloil #2

Agreed this is a limitation – we do have a request on the backlog to add it (github.com/.../997) but won’t be doing it immediately.
We suggest folks do this as it tends to make N-Tier scenarios easier and also avoids some behavior nuances in EF6 (that no longer exist in EF7). While a subset of folks care a lot about the shape of the model and we want to make EF work well for them, the vast majority of developers have no issues with including the FK property in their model and it does make several things easier. #5 – We’re actually about to start some design work around what happens when EF discovers new objects that it wasn’t aware of. The ‘just mark everything as added’ approach of EF6 is definitely not ideal. Here is the work item github.com/.../323. We’re going to design now but may not have everything implemented for the initial release (but will at least lay the right ground work).

Anonymous
January 05, 2015
First, thanks for all the effort to communicate where you are going with Entity Framework 7. I am a fan of RIA Services, and have converted to Open RIA Services. I very much appreciate RIA Service's ability to define a model on the server, and then have that domain duplicated on the client, and to then have the ability to save a 'unit of work' from the client back to the server. With EF7 available on the client, it seems like it may provide some of the functionality previously made available by RIA Services. But I don't see any mention of EF7's capability of duplicating a model that was created on the server, nor of the related capability of keeping a client store synced up with a server store. Does that make sense? Will EF7 have syncing capabilities of...

duplicating a server model on the client, and
syncing changes made on the client back to the server

Anonymous
January 05, 2015
@ReeseWatt - EF won't have this kind of functionality built in. You could implement something like this by having an EF7 provider on the client that applies changes by talking to a service that uses the actual database provider to write the changes to the store (but it's not something we are looking at right now).
Anonymous
January 05, 2015
@ReeseWatt: Another option would be to extend Open RIA to work with EF7.
Anonymous
January 11, 2015
The comment has been removed
Anonymous
January 12, 2015
@Yolk around devs neck - Glad the direction sounds good to you.
Anonymous
January 13, 2015
The comment has been removed
Anonymous
January 15, 2015
@Miki - That is a valid approach and no one here is going to try and talk you out of it. If you have a data access technology that works for you then that's ultimately what we want. There are plenty of folks who like EF (and other similar O/RMs), but we're not trying to build the one tool to rule them all. We want to give .NET developers the right range of tools in their belt and let them chose what they prefer to work with.
Anonymous
January 17, 2015
Nice
Anonymous
January 18, 2015
Will it support natively sequences as default values for primary keys? After inserting a row in such a table, will I be able to get the value assingned, as I did with identity?
Anonymous
January 19, 2015
@Mariel - Yes, sequence support is included.
Anonymous
February 09, 2015
What's happening to this development as it appears to be some time since any update!
Anonymous
February 09, 2015
I'm assuming this is the page to watch blogs.msdn.com/.../ef7-priorities-focus-and-initial-release.aspx
Anonymous
February 10, 2015
@Nick - We blog when there are major developments/releases/decisions etc. but at this stage we are mostly heads down on implementation. Here is the GitHub project if you want to follow along with our day-to-day development github.com/.../EntityFramework.
Anonymous
March 15, 2015
Wow. Great discussion. Learned a lot. Thanks, everyone.
Anonymous
May 04, 2015
sorry , i don't know how to use the ef7.0 for my Stored Procedure.
Anonymous
May 12, 2015
@John - EF7 doesn't have stored procedure support as yet (I'm posting this while Beta 4 is available). You can track the feature here github.com/.../245.
Anonymous
July 30, 2015
It would be useful if you could explicitly materialise entities using database value. Entry has current, original and database. If you read and entity graph using linq, modify it you only get the current values, to see what is in the database it would be useful if you could ask for this. This would be very useful in disconnected more. Read in an object graph attach disconnected objects and then compare values. At the moment you have to use something like AsNoTracking which may require an extra call to the db if the entities have already been read in and modified
Anonymous
September 08, 2015
Any Improvement in first query time ?? Because now it is very slow for load Model first time and any possibility to cache MetadataWorkspace and O-C mapping of Entities in persistence storage ??
Anonymous
October 26, 2015
The comment has been removed
Anonymous
November 18, 2015
@Ian McInnes – In EF6 you can do this for individual entities via the ChangeTracker API. I’m not sure how generally useful it is for a whole query since you need query the database to work out what entities match your query – at which point getting the data from the original values in the change tracker vs. just getting them from the data reader is probably not that much of an advantage.
Anonymous
November 18, 2015
@Mehul – Our working code base for EF7 is seeing more and more scenarios become faster than EF6.
Anonymous
November 18, 2015
@Derek – EF providers are typically written by the database owners rather than our team. This approach ends up with the best provider (since it can be optimized for the nuances of the database). It also tends to result in providers being kept up-to-date, since there are only so many providers our team can work on. We are working with provider writers to support EF7. Postgres is currently supported and we agree that Oracle and MySQL are both essential for Linux.
Anonymous
November 18, 2015
10 years later and MS has no support for databases outside of MSSQL and Azure Table storage... where is Postgres support, JSONB Postgres support. I can use Ruby on Rails ActiveRecord and run 'gem install pg' and I get JSONB support. I can run Knex/Bookshelf on Node and get migrations and Postgres JSONB support. But EF and it's team of 10+ years still can't run on open source solutions ? Open source to me is more than just 'we are showing you the code now' - it means it runs on other platforms and a variety of databases. Why so far behind after 10 years (which is an eternity) ???
Anonymous
November 19, 2015
@Steve – EF6 has providers for Postgres, Oracle, MySQL, DB2, SQLite, Firebird and many others. Hopefully we are doing better than “we are showing you the code now”… we have been collaborating with various folks to build an ecosystem of providers for EF7. We build some ourselves, and others are built by third parties. Our third party providers have also contributed code back into our core code base to fix issues they hit and better support their providers. We also take code contributions from other folks too.

Bagikan melalui