Load Entities AsNoTracking() with navigation properties, without specifying includes

c# entity-framework

Question

If the scenario below is feasible using Entity Framework, please let me know:

I want to use the option to load numerous tables.AsNoTracking since none of them can be altered by the user and are all static tables.

Additionally, their tables serve as other people's navigational assets. I've been relying on theAutoMapping utilize the Entity Framework's functionality instead of the.Include() or LazyLoading functionality.

thus as opposed to:

var result = from x in context.TestTable
          .Include("ChildTestTable")
select x;

This is how I'm use it:

context.ChildTestTable.Load();
context.TestTable.Load();
var result = context.TestTable.Local;

This is functioning well since the application is built in such a way that the database's tables are quite small; there won't be any tables with more than 600 rows (and in my app, 600 rows is already a rather high value).

My current method of loading data isn't functioning with.AsNoTracking() . Is it possible to make it operate in any way?

I can now type:

context.ChildTestTable.AsNoTracking().List();
var result = context.TestTable.AsNoTracking().List();

in place of

var result = from x in context.TestTable.AsNoTracking()
          .Include("ChildTestTable")
select x;

Basically, I'd like one or more tables filled withAutoMapping Is it possible to turn on the feature without loading them into the Object State Manager?

1
10
3/29/2020 10:11:22 AM

Accepted Answer

Simple no is the response. The state manager is used for identity resolution (finding a previously loaded instance of a particular entity and using it rather than creating a new instance) and fixup for typical tracking queries (connecting navigation properties together). When you use a no-tracking query, it indicates that the state manager does not track the entities. As a result, fixup between entities from various queries is impossible since EF is unable to locate such instances.

Include would try to conduct some fixup between entities within the query if it were used with a no-tracking query, and this would frequently succeed. However, certain queries may reference the same thing more than once. In those instances, EF may not be able to determine that the entity being referenced is the same, which could lead to duplicate results.

What you don't really express is why you want to utilize no-tracking, I suppose. Although numerous things can affect this, you probably won't see a substantial performance boost if your tables don't have a lot of data. (A side note: If the data never changes, using the ObservableCollection produced by.Local should not be necessary and could negatively affect performance.) In general, you should only use no-tracking if you explicitly need to do so because otherwise, it adds complexity without providing any value.

13
11/29/2013 4:46:07 PM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow