It depends, try both
When using Include()
, you get the benefit of loading all of your data in a single call to the underlying data store. If this is a remote SQL Server, for example, that can be a major performance boost.
The downside is that Include()
queries tend to get really complicated, especially if you have any filters (Where()
calls, for example) or try to do any grouping. EF will generate very heavily nested queries using sub-SELECT
and APPLY
statements to get the data you want. It is also much less efficient -- you get back a single row of data with every possible child-object column in it, so data for your top level objects will be repeated a lot of times. (For example, a single parent object with 10 children will product 10 rows, each with the same data for the parent-object's columns.) I've had single EF queries get so complex they caused deadlocks when running at the same time as EF update logic.
The Load()
method is much simpler. Each query is a single, easy, straightforward SELECT
statement against a single table. These are much easier in every possible way, except you have to do many of them (possibly many times more). If you have nested collections of collections, you may even need to loop through your top level objects and Load
their sub-objects. It can get out of hand.
Quick rule-of-thumb
Try to avoid having any more than three Include
calls in a single query. I find that EF's queries get too ugly to recognize beyond that; it also matches my rule-of-thumb for SQL Server queries, that up to four JOIN statements in a single query works very well, but after that it's time to consider refactoring.
However, all of that is only a starting point.
It depends on your schema, your environment, your data, and many other factors.
In the end, you will just need to try it out each way.
Pick a reasonable "default" pattern to use, see if it's good enough, and if not, optimize to taste.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…