LINQ to SQL | Entity |
|
|
Tuesday, April 30, 2019
Mention what is the difference between LINQ to SQL and Entity Framework?
Explain Lazy loading, Eager Loading, and Explicit Loading?
- Lazy Loading: It is a process to delay the loading of related objects until it is required.
- Eager Loading: It occurs when you query for an object and all of the related objects are also returned. In eager loading, related objects are loaded automatically with its parent object
- Explicit Loading: Explicitly loading takes place when you have disabled Lazy loading, and you still want to lazy loading. For this, we have to call the load method on the related entities.
How can you enhance the performance of Entity Framework?
To enhance the performance of Entity Framework, you have to follow the following steps:
- Try to avoid to put all the DB objects into one single entity model
- Disable change tracking for entity if not needed
- Reduce response time for the first request by using pre-generating Views
- If not required try to avoid fetching all the fields
- For data manipulation select appropriate collection
- Wherever needed use compiled query
- Avoid using Views and Contains
- While binding data to grid or paging, retrieve only required no of records
- Debug and Optimize LINQ query
Sunday, April 14, 2019
Persistence in Entity Framework
There are two scenarios when persisting (saving) an entity to the database using Entity Framework: the Connected Scenario and the Disconnected Scenario.
Connected Scenario
In the connected scenario, the same instance of the context class (derived from DbContext) is used in retrieving and saving entities. It keeps track of all entities during its lifetime. This is useful in windows applications with the local database or the database on the same network.
Pros:
- Performs fast.
- The context keeps track of all entities and automatically sets an appropriate state as and when changes occurr to entities.
Cons:
- The context stays alive, so the connection with the database stays open.
- Utilizes more resources.
Disconnected Scenario
In the disconnected scenario, different instances of the context are used to retrieve and save entities to the database. An instance of the context is disposed after retrieving data and a new instance is created to save entities to the database.
The disconnected scenario is complex because an instance of the context doesn't track entities, so you must set an appropriate state to each entity before saving entities using
SaveChanges()
. In the figure above, the application retrieves an entity graph using Context 1 and then the application performs some CUD (Create, Update, Delete) operations using Context 2. Context 2 doesn't know what operation has been performed on the entity graph in this scenario.
This is useful in web applications or applications with a remote database.
Pros:
- Utilizes less resources compared to the connected scenario.
- No open connection with the database.
Cons:
- Need to set an appropriate state to each entity before saving.
- Performs slower than the connected scenario.
Subscribe to:
Posts (Atom)