EF6 or EF Core? How Do I Choose?

Editor's Notes

• #10: Like EF6, EF Core is open source and available on Github. Notice the URL is github.com/aspnet/entityframework. You can watch it evolve, raise issues that you may discover, download and use the latest bits even if they aren’t officially released yet and most importantly, you can submit your own fixes or features to become part of EF Core. Any pull requests that are submitted from the community go through a rigorous examination before they are accepted into the official code base. EF6 was moved from codeplex to github in mid-2016 and it’s repository is also part of the aspnet group.
• #13: The most notable feature that is not coming forward into EF Core is the entity framework designer and the designer based model – the EDMX. There is no way to sugar coat this for developers who have ecisting apps that use EDMX. Personally, I haven’t used the designer in a long time. I happen to be more comfortable with code first. But that doesn’t mean it’s not a useful or important workflow for developers so I have enormous empathy for developers who are very unhappy about this decision. Also, just because Micfrosoft will not be providing support for the designer based model, that doesn’t mean all is lost. There are third party companies that already provide alternate designers for entity models. [CLICK] DevArt has a designer called Entity Developer. I asked them about possible support for EF7 and they said that they are currently considering it. [CLICK]Another alternate to Microsoft’s entity framework designer is one provided in LLBLGen Pro. That designer already supports code first for EF6 and earlier versions and it’s creator, Frans Bouma, says that he is planning to also support EF7 and doesn’t anticipate any problems adding that support. Also, many developers worry that no designer means no database first. The database first and code first monikers have always been a little misleading. [CLICK] Database first refers to reverse engineering and existing database into an edmx to be used in the designer. Code first really just means no designer. It is absolutely possible to reverse engineer an existing database and use it with code first … without a designer. We’ve been able to do this since code first was released thanks to the entity framework power tools. The current EF designer for visual studio 2012 and 2013 lets you do this. [CLICK] And there are also a few 3rd party tools like the very popular EF Reverse Poco code first generator by Simon Hughes. That’s is on code plex and can be installed as an extension to visual studio and its free. The EF team definitely plans to provide a means of letting you reverse engineer from existing databases to EF7 models as well. The EF power tools also used the designer to provide an important capability for develoeprs using code first which was to visualize the model we are defining. I use that all the time and can’t use code first without that tool. The team assured me that they already working on making sure we have something comparable for EF7.
• #19: cutting the designer based EDMX from EF Core is what I’ve heard the most feedback about. But There are other EF features that are also getting cut. these are not as worrisome to developers, based on my own experience and paying attention to response in social media but it’s important to be aware of the biggest of these cut features. Look for a link in the resources list pointing to a blog post I’ve written with more details about why each of these features will not be in Entity Framewrok Core. <Click> The first is the ObjectCOntext API. This is the original mechanism for EF’s change tracking and database interaction. Since EF4.1 was released with the DbContext in early 2011, Microsoft has recommended that all new projects use DbContext and let it do the more cumbersome work of interacting with the ObjectContext. But the Objectcontext has remained a public API for backwards compatibility with EF4 and EF3.5 projects. Also, we could access the obje ctcontext to do low level tasks if needed. The ObjectContext API will be removed from EFcore completely. Rather than relying on the ObjectContext for metadata work, change tracking and database interaction, this lowlevel activity is being restructured and we’ll get all of it directly from the DbContext. If you have old software that is still using the ObjectContext and you haven’t updated it by now, hopefully, you won’t want to update it to EFcore anyway. I wrote a two part article for MSDN magazine that included guidance for moving ObjectCOntext code to DbContext if you think you may want to explore that. <CLICK>Entity SQL was the original string based querying SQL like language written for EF but by the teim EF was first released, it had already embraced LINQ. ESQL is only usable with the ObjecctContext API. I think I used to be one of the few people in the world who really knew how to use ESQL beasue I wrote about it extensively in my first EF book, giving it equal visibility as LINQ to entities. In the 2nd edition, I had split the ESQL details out into their own chapter beause by then it was clear that it was barely being used. I haven’t had any reason to use ESQL in many years. I’ve not heard of anyone using it either. So it is going to fade away along with the ObjectContext API and won’t be part of EFCore. <CLICK>Entity framework has allowed a lot of variations on mappings fro m your classes to your database objects and fields. It even let you combine many of these crazy mappings in one model, the EF team blog post highlights the example of “ 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” It was possible because of the metadata workspace API. But building in this flexibility also meant that using that API was very complex, made query compilation difficult and for developers, discovering information about a model’s metadata has been very cumbersome. <CLICK>So EFCore has a simpler metadata model which means some the truly edge case mappings won’t be achievable. This doesn’t mean things like inheritance will go away (although currently, EF Core only supports TPH), just the funky, rare mapping combinations. <CLICK>The one single mapping technique that will go away is MEST. In all of my years of working with EF, I’ve never come across anyone who was taking advantage of it. It was only supported with EDMX and ObjectContext and the team decided not to try to bring it forward to the code-based model and DbContext for EFCore. <CLICK>Migrations are a critical technique for evolving a database schema from a code-based model. We’ve had two ways to use EF migrations – the default way which is to explicitly add migrations through the package manager console and then to apply thoe migrations using a variety of techniques. Another option has been to use automatic migrations that are worked out and executed on the fly at run time. Supporting automatic migrations caused a number of major headaches for migrations support overall. It forced migrations to store model snapshots directly in the database. This caused problems for developers using regular migrations. I’ve been in loops where I can’t add a migration because it thinks I need to apply one, but when I try to execute a migration it tells me I have to add one. I’m not the only one who has gotten all tangled up in some circular problems when trying to manage migrations. These problems will go away because EFCore will not attempt to automate migrations at all. You can read more about this in Brice Lambson’s blog posts about EFCore Migrations which I’ll link to in the resources at the end of this module. . Brice is an engineer on the EF team. So these are the most notable EF features that the team is not planning to implement at all in EFCore. Personally, I have not been using any of them ever or in a long time and I have guided my clients away from them as well. So if you are on that same path, you are well-positioned to use EF Core without having to worry about them.