Entity Framework Lifecycle - Microsoft Entity Framework

What is Entity Framework Lifecycle?

Lifetime

The lifetime of a framework begins when the instance is formed and ends when the instance is either prepared or garbage-collected.

  • Context lifetime is a very critical decision to make when we use ORMs.
  • The context is performing like an entity cache, so it means it holds references to all the loaded objects which may grow very fast in memory consumption and it can also cause memory leaks.
  • In the below diagram, you can see the upper level of data workflow from application to database via Context and vice versa.

data_workflow


Entity Lifecycle

The Entity Lifecycle defines the process in which an Entity is created, added, modified, deleted, etc. Entities have many states during its lifetime. Before looking at how to retrieve entity state, let’s take a look at what is entity state. The state is an enemy of type System.Data.EntityState that states the following morals −

  • Added: The entity is marked as added.
  • Deleted: The entity is marked as deleted.
  • Modified: The entity has been modified.
  • Unchanged: The entity hasn’t been modified.
  • Detached: The entity isn’t tracked.

State Changes in the Entity Lifecycle

Sometimes state of entities is set automatically by the context, but it can also be changed automatically by the designer. Even though all the combinations of switches from one state to another are possible, but some of them are meaningless. For instance, added entity to the Deleted state, or vice versa.

Let’s debate about different states.

Unchanged State

  • When an entity is Unchanged, it’s bound to the context but it hasn’t been adapted.
  • By default, an entity saved from the database is in this state.
  • When an entity is attached to the context (with the Attach method), it similarly is in the Unchanged state.
  • The context can’t track changes to objects that it doesn’t reference, so when they’re committed it assumes they’re Unchanged.

Detached State

  • Detached is the default state of a newly formed entity because the context can’t track the design of any object in your code.
  • This is true even if you instantiate the entity inside a using block of the framework.
  • Separate is even the state of entities retrieved from the database when tracking is stopped.
  • When an entity is detached, it isn’t bound to the context, so its state isn’t tracked.
  • It can be prepared of, changed, used in combination with other classes, or used in any other way you might need.
  • Since there is no context tracking it, it has no meaning to Entity Framework.

Added State

  • When an entity is in the Added state, you have few options. In fact, you can only remove it from the context.
  • Certainly, even if you change some property, the state remains Added, because moving it to Adapted, Unchanged, or Deleted makes no sense.
  • It’s a new entity and has no communication with a row in the database.
  • This is a fundamental requirement for being in one of those states (but this rule isn’t enforced by the context).

added_state

Modified State

  • When an entity is altered, that means it was in unchanged state and then some property was different.
  • After an entity enters the Modified state, it can move to the Detached or Deleted state, but it can’t roll back to the unchanged state even if you automatically restore the unique values.
  • It can’t even be altered to Added, unless you detach and add the entity to the context, because a row with this ID already exists in the database, and you would get a runtime exception when persisting it.

Deleted State

  • An entity enters the Deleted state because it was Unchanged or Altered and then the Delete Object method was used.
  • This is the most constricting state, because it’s pointless changing from this state to any other value but Disconnected.

The using statement if you want all the properties that the context controls to be prepared at the end of the block. When you use the using statement, then compiler automatically creates a try/finally block and calls arrange in the finally block.

When working with long-running context consider the following −

  • As you load more objects and their references into memory, the memory consumption of the context may increase rapidly. This may cause performance issues.
  • Remember to dispose of the context when it is no longer mandatory.
  • If an exception causes the context to be in an unrecoverable state, the whole application may dismiss.
  • The chance of running into concurrency-related issues increases as the gap between the time when the data is queried and updated grows.
  • When working with Web applications, use a context example per request.
  • When working with Windows Presentation Foundation (WPF) or Windows Forms, use a context example per form. This lets you use change-tracking functionality that context offers.

Rules of Thumb

Web Applications

  • It is now a corporate and best preparation that for web applications, context is used per request.
  • In web applications, we contract with requests that are very short but hold all the server transaction they are therefore the correct time for the context to live in.

Desktop Applications

  • For desktop application, like Win Forms/WPF, etc. the context is used per form/dialog/page.
  • Since we don’t want to have the context as a singleton for our application we will arrange it when we move from one form to another.
  • In this way, we will gain a lot of the context’s abilities and won’t suffer from the consequences of long running contexts.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Microsoft Entity Framework Topics