EF6 or EF Core? How Do I Choose?


Published on

Oct 2016 Presentation at DevIntersection.
By one of the most respected authorities on Entity Framework.

Published in: Software
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • 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.

  • 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.

  • EF6 or EF Core? How Do I Choose?

    1. 1. EF Core or EF 6 How Do I Choose? Julie Lerman @julielerman about.me/julielerman
    2. 2. Entity Framework in the Enterprise (Update) Play by Play: First Look at EF Core Getting Started with EF6 Domain-Driven Design Fundamentals Looking Ahead to Entity Framework 7 EF6 Ninja Edition: What’s New in EF6 Automated Testing for Fraidy Cats Like Me Getting Started with Entity Framework 5 Entity Framework Code First Migrations Data Layer Validation with Entity Framework 4.1+ Entity Framework 4.1 - DbContext Data Access Entity Framework 4.1 - Code First Querying the Entity Framework Designer Supported EDM Customization Entity Framework and Data Models Entity Framework 4.0 By Example My Courses on
    3. 3. Important Information Demos Prepare/migrate EF6 code Q&A
    4. 4. From Entity Framework to EF Core EF 2008 EF4 2010 4.1 2011 5 2012 6 2013 EF Core 1.0 June 2016 EF Core 1.1 Q4’16/Q1’17 6.13- > 6M downloads
    5. 5. New features Cross-platform New code base Performance++ 8 Years 6M+ downloads “battle tested” V6 brought advanced features EF6 or EF Core?
    6. 6. Unified platform .NET STANDARD LIBRARY
    7. 7. Ready for Limited Primetime Stable Performant Integrates with ASP.NET Core Cross Platform Downsides today - features - tooling - .Net Core is a moving target
    8. 8. .NET & Windows ASP.NET Core X Platform .NET Core EF Core Unless you are truly compelled by EF Core EF6
    9. 9. ASP.NET Core & EF6
    10. 10. EF Core 1.0.0 EF Core 1.0.0 EF Core 1.1.0 EF Core 1.1.0 EF6 Feature Set EF Core >1.1.0 EF Core >1.1.0 Never coming to EF Core NewLimitedParity EF6 Features vs EF Core Features
    11. 11. bit.ly/efcoreroadmap ”EF6.x continues to be the best version of EF for a number of applications until these features are implemented”
    12. 12. No Microsoft EDMX/Designer
    13. 13. Reverse Engineer in EF Core EF Core Migrations scaffold command
    14. 14. You do not have to re-learn everything
    15. 15. But… it’s still new & different
    16. 16. The Big Q’s We’re starting a new app. Should we use EF6 or EF Core? We’re updating our app. Should we use EF Core? EF6? Wait?
    17. 17. Existing Migration not Upgrade Not backwards compat Missing features Eliminated features Don’t, Unless You Must!* New Apps “V.1” Comfort? Feature Decision .NET Core : EF Core
    18. 18. Biggest Planned Feature Cuts EDMX Support ObjectContext API Entity SQL Metadata Workspace API Overly complex mappings MEST* mapping Automatic Migrations *Multiple Entities for Single Type
    19. 19. EF6 EF Core Production Ready Actively Evolving Visual Designer *expect 3rd party support Backwards Compatible Full .NET Support .NET Core Support Lightweight API(s) Better APIs, New Features Non-Relational Data *coming post 1.1 Open-Source (on Github) *4.5.1 +
    20. 20. Migrating Code Simple models and code with Code First, DbContext, Migrations
    21. 21. Migrating Code Simple models and code with Code First, DbContext, Migrations Complex models and code with Code First, DbContext, Migrations
    22. 22. Migrating Code Simple models and code with Code First, DbContext, Migrations Complex models and code with Code First, DbContext, Migrations Small EDMX models, simple actions, with DbContext
    23. 23. Migrating Code Simple models and code with Code First, DbContext, Migrations Complex models and code with Code First, DbContext, Migrations Small EDMX models, simple actions, with DbContext Large EDMX, mappings, not so simple interaction, DbContext
    24. 24. Migrating Code Simple models and code with Code First, DbContext, Migrations Complex models and code with Code First, DbContext, Migrations Small EDMX models, simple actions, with DbContext Large EDMX, mappings, not so simple interaction, DbContext ObjectContext, ESQL
    25. 25. EF6 EF Core Existing Code
    26. 26. Build with EF6, keeping EF Core in mind
    27. 27. Isolate and Update Parts of Your App
    28. 28. public Thing GetThatThing() { return Data.GetThatThing(); } IData EF6.Data : IData EFCore.Data : IData
    29. 29. Bottom Line for Near Future EF Core is best for new, .Net Core apps Know what is and is not there Use it if you know it suits you Be very picky about EF6->EFCore Use EF6 until EF Core is ready for you Plan ahead with good design
    30. 30. Resources Pluralsight: Play by Play : EF Core First Look (bit.ly/PS_EFCoreLook) Coming soon: Getting Started with EF Core EF Docs: docs.efproject.net EFCore: github.com/aspnet/entityframework EF6: github.com/aspnet/entityframework6 Roadmap: bit.ly/efcoreroadmap Julie Lerman TheDataFarm.com @julielerman
    31. 31. Julie Lerman @julielerman about.me/julielerman