By selecting every column (effectively running a “ Select * From…” query), we make it almost imÂpossÂible to index the database usefully.In the example here it’s particularly frustrating because although we just want the small FirstName and LastName strings, the Pupils table includes a large Picture column which is retrieved unnecessarily and never used. This impacts everything from SQL Server I/O and network performance, through to memory usage in our client application. We’re transferring more data than necessary.The problem here is that, at the point when the query is run, EF has no idea what properties you might want to read, so its only option is to retrieve all of an entity’s properties, i.e. To do this your first line would read:īy taking a look in ANTS at the query which has been run, we can see that a lot more data than the first and last names ( FirstName and LastName) has been retrieved.
Since the Pupils data would be in memory, there would be no need for Entity Framework to hit the database again. The first is to use the Eager Loading data access strategy, which fetches the related data in a single query when you use an Include() statement. There are a couple of different approaches available. This is particularly important if there is high latency between your application and the database server.
If you know that you’re definitely going to want the Pupil data, you’d be better doing things differently – especially if you want it for a large number of School objects.
#ENTITY FRAMEWORK EF NOT IN COMMAND LINE PLUS#
This leads to the name “N+1 select problem”, because N plus 1 queries are executed, where N is the number of objects returned by the original query. But in the example above, Entity Framework makes an initial request to retrieve the list of Schools, and then has to make a separate query for each of the 500 Schools returned to fetch the pupil data. Most of the time that’s a good idea because otherwise any time you accessed a School object, EF would bring back all related Pupil data regardless of whether it were needed. If you subsequently try to access data from one of the related Pupil objects, only then will it be retrieved from the database. This happens because by default, EF uses a loading strategy called Lazy Loading, where it doesn’t fetch any data associated with the virtual Pupils property on the School object when the first query is run.
#ENTITY FRAMEWORK EF NOT IN COMMAND LINE CODE#
If we look in ANTS at what happens when this code runs, we see a query run once to get a list of schools in New York, but another query is also run 500 times to fetch Pupil information. Database accessīy far the biggest performance issues you’re likely to encounter are of course around accessing the database. – setup instructions are included in the readme. To play along at home, you can grab the code for most of these examples from There’s a database with two tables for Schools and their Pupils, and a WinForms app using an EF code-first model of this database to fetch data in a variety of inefficient ways. We’ll use examples from a simplified school management system. In this article we’ll look at where these ‘traps’ are hiding, examining how they can be spotted and what you can do about them. Unfortunately, several traps that are easy to fall into have given it a reputation for performing poorly but it doesn’t have to be this way! The performance of Entity Framework may once have been inherently poor but isn’t any more if you know where the landmines are. Compared to writing your own SQL to access data, you can become miraculously more productive by using Entity Framework (EF).
0 kommentar(er)
