Entity Framework 6 and EF Core
We support applications whose data access is built on Entity Framework, find the queries that make them slow, and move them from Entity Framework 6 to EF Core as part of a staged move to modern .NET.
What you probably want to know first
- Our application has become slow. Is Entity Framework the problem?
- Often it is how Entity Framework is used rather than Entity Framework itself. The usual causes are lazy loading that fires hundreds of small queries for one screen, whole records loaded when two columns were needed, and change tracking left on for read-only screens. We measure first, from the monitoring and the database's own records, so the fixes go where the time is actually spent.
- Do we have to change the database to move to EF Core?
- No. EF Core can be mapped onto the existing database as it stands, so the old and new parts of the application can share it during a migration. Schema changes, if any are worth making, come later and one at a time.
- What access do you need?
- Read access to the source code and, for performance work, read-only access to the database server or a recent copy of the database. We do not change the live database while investigating.
- What have you done with systems like this?
- OpenIRIS uses Entity Framework 6 in its original application and EF Core in its new ASP.NET Core API, both mapped onto the same SQL Server database of around 230 tables. The OpenIRIS case study describes the system.
Who this page is for
This page is for managers responsible for a .NET business application that stores its data in SQL Server through Entity Framework, where the system has slowed down as it has grown, or is moving to modern .NET and needs its data access to move too.
Why Entity Framework applications slow down
Entity Framework makes it easy to write data access quickly, and the same ease lets inefficient patterns spread unnoticed while the data is small. The common ones are:
- Lazy loading. Touching a related record quietly fires another query. A list of 200 bookings that each show their resource and user can become 400 extra round trips.
- Loading whole records. A screen that shows four columns loads all of them, including large text and binary columns.
- Tracking what will never be saved. Read-only screens pay for change tracking they do not need.
- Queries built in a loop. Code that runs a query per item instead of one query for all of them.
None of these needs a rewrite. They are found by measuring, then fixed one screen at a time, starting with the screens people use most.
Moving to EF Core without a big switch
EF Core is the version of Entity Framework that modern .NET development uses. It can sit on the same database as the existing application, so the move does not need a data migration or a cut-over weekend. New parts of the system are written against EF Core from the start, older parts move across as they are touched, and tests compare the results of old and new code against the same data.
This is the approach OpenIRIS is taking, where the original application on Entity Framework 6 and the new ASP.NET Core API on EF Core share one SQL Server database.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss your Entity Framework application 0800 433 7990What we do with Entity Framework applications
- Find the slow queries
- We trace slow screens to the queries behind them and to the line of code that generates them.
- Stop the query storms
- Lazy loading that turns one screen into hundreds of round trips is replaced with queries that fetch what the screen needs in one go.
- Load less
- Read-only screens project just the columns they show and skip change tracking.
- Move to EF Core
- Data access moves to EF Core on the existing database, area by area, alongside a staged move to modern .NET.
- Tidy the model
- Inconsistent naming, soft-delete patterns and link tables are hidden behind a clean model without a risky schema rewrite.
- Test against a real database
- Integration tests run against SQL Server, not an in-memory stand-in, so query behaviour is what production will see.
How a move from EF6 to EF Core runs
Map the existing database
EF Core is mapped onto the database as it is, with nothing changed in production.
Move one area at a time
Each area's queries and updates move to EF Core in the new application while the old one carries on.
Compare old and new
Tests check that the new code returns the same results as the old for the same data.
Retire the EF6 code
When the last area has moved, the old data access is removed.
A good fit when
- Screens or reports have become slow as the data has grown.
- The application is moving from .NET Framework to modern .NET.
- Nobody on the current team understands how the data model fits together.
Probably not for you if
- The database belongs to a packaged product whose vendor controls its schema and queries.
Questions we are asked
Is Entity Framework 6 still supported?
Entity Framework 6 runs on .NET Framework and on modern .NET and still receives occasional fixes, but new development happens in EF Core. An application that is otherwise moving to modern .NET should plan to move its data access too.
Would we be better off with stored procedures?
Sometimes, for a small number of heavy reports. For most of an application, well-written EF Core queries perform well and are far easier to change and test. We use whichever fits the job and say why.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.