How does Entityframework’s Tracking / Chache work?

Question

Every time I used the Entityframework in a project, to add a record in the database through it, of a class that contains class type members (usually on account of Foreignkeys), I would do this:

1. After the entity instance, it filled the properties of primitive types;
2. Set class type properties to null.

And so it always worked for me, until in a specific case like the one I presented in that question: Entityframework complaining of Identifier duplicity even with the property being null.

There are some issues here that address this issue, always isolated cases and a way around.

1. How, after all, does the Tracking of objects of Entityframework?

2. When working with ASP.NET MVC (web projects) it works in a way that does not keep information in memory. That is, the context of Entityframework and all other things are instantiated when a request is made and destroyed when it finishes returning its result. So whenever I make a POST for a Action, that will make the bind of a class as a parameter of Action, I know I have an instance not monitored by Entityframework, right? Why then a simple:

    if (ModelState.IsValid)
    {
        _context.Add(model);
        _context.SaveChanges();
    }

Works?

3. As in the case of the question I referenced, because there were monitoring problems?

4. What would be the most "complete" way to deal with Inserts and Updates and have no problems with the Tracking object?

5. Enable or Disable the LazyLoading and creation of proxies and monitoring of changes (AutoDetectChangesEnabled) affects how the Tracking?

Answer 1

It’s a lot of questions to answer, and a little complicated, but I’ll try

1 - Entityframework Changetracking now monitors an instance of an entity after it is "attached" (attached) to an instance of a Dbcontext.

2 - When you call a method from a Dbset, for example, Add(T model), the Entityframework will attach the object to Dbcontext and mark its state as Added.

Remembering that you cannot attach the same object to two distinct instances of Dbcontext

You can check the current state of an object through the Entry(Object instance method).

3 - Entityframework uses the Identity Map Pattern. With this, an instance of Dbcontext can only have a single instance of an object with the same key (Primary Key) attached to the Changetracker. For example, if you loaded the record with the Id = 1 of a Person entity, you cannot attach another object with the same Id = 1, otherwise you will have problems.

4 - The best way to treat Inserts and updates is to isolate operations with entities in a manner similar to a transaction. An instance of a Dbcontext must have a short life, that is, you instantiate Dbcontext, do what you need and then discard the instance. I need to improve the answer to this question 4, but I’ll say that there is a very good Nuget package to treat more complex updates, called Graphdiff.

5 - I do not use Lazyloading, nor recommend, I prefer to have full control over what I want to load from my database and when necessary I upload the data I will need, using Include(). So by default I disable. Lazy Loading requires the creation of proxy classes, and requires the Entity properties to be virtual. Regarding Autodetectchanges, if disabled, you will have to call the Detectchanges() method manually so that Entityframework discovers which properties have been modified when generating SQL updating entities.

Answer 2

How, after all, does the Tracking of objects of Entityframework?

First it is important to explain that a context exists during the life cycle of a Controller, in the specific case you are working using MVC. The values loaded by Controller are only expired when the Controller in question suffers a Dispose, making the context also suffer a Dispose.

When loading an object (in English they call entry, and I’ll call it a record), the record is loaded with the original values of the database, and they stay there even if you change the record. This makes it clear that when modifying a record, the Entity Framework knows that this record has already been loaded and knows what to change.

The record is usually located by its key. To understand this better, you need to understand the implementation of DbSet<T>. He’s an observable collection (ObservableCollection). By calling SaveChanges, what is being done is:

1. Check if any collection is marked as changed;
2. For each record that has been marked as changed, the Entity Framework performs some logical operation to insert, update, or delete a record in the database. The executed instruction is linked to EntityState, one Enum used to identify the state of the registry within the Entity Framework.

So, whenever I do a POST for an Action, which will bind a class according to the Action parameter, I know that I have an instance not monitored by the Entityframework, right?

Wrong. If the record has already been loaded previously (in a Edit, for example), it is already being "observed". When applying a POST to save the edit, the object coming from View is synchronized as follows:

context.Entry(obj).State = EntityState.Modified;

Note that the context here is a new context, without the information of the previous request. When I say "the record has already been loaded," I say it was loaded on screen, not on Controller. When performing the POST, you are sending information and the context works optimistically, that is, the record is again loaded in Entry() if it has not already been loaded.

In this line are made two things:

1. Locate a record based on another;
2. Update the values of the observed record based on the on-screen records.

The case of Add is simpler. You are telling the context that the object does not exist, so the context considers the object as new.

As in the case of the question I referenced, because there were monitoring problems?

I’ll answer the question.

What would be the most "complete" way to deal with Inserts and Updates and have no problems with the Tracking object?

• Not implementing repositories (Entity Framework already implements repositories);
• Not implementing Service layer (Controller is already a different layer of services, but is);
• Not instantiating two contexts unnecessarily;
• Not selecting objects in one context and trying to save in the other;
• Using the simplest code possible, as (almost) all examples illustrated here and on other specialized websites.

Enable or Disable the LazyLoading and creation of proxies and monitoring of changes (AutoDetectChangesEnabled) affects how the Tracking?

Lazy loading and monitoring are independent things. One does not affect the other and vice versa.

AutoDetectChangesEnabled does the tracking does not work. Any change has to be invoked by manual methods.