CODEWITHSUNDEEP
c#.netentity-frameworkdesign-patternsentity-framework-core
ArturoO
ArturoO

Reputation: 611

Using DbContext instance inside the entity class

Recently I've started learning Entity Framework Core and I'm curious if it's fine to use DbContext instance inside the entity class.

Sample code:

class User {
    public int Id { get; set; }
    public string Name { get; set; }
    public ICollection<Order> Orders { get; set; }

    public void LoadOrders() {
        using (var context = new StoreContext()) {
            Orders = context.Orders             
                .Where(x => x.UserId == Id)
                .ToList();
        }
    }
}

User entity has a relation with Order class, both of them have appropriate tables in the DataBase created using migrations from Entity Framework. The purpose of LoadOrders() method is simply to load related entities for current user when it's necessary.

Now I wanted to know if that's a valid approach?

Or maybe I should always load related entities at the same time when I'm loading the parent object? (E.g. .Include().ThenInclude())

Or maybe the code of LoadOrders() method should be located in some additional class like UserHelper that would be used along with the User entity.

Upvotes: 1

Views: 1117

Answers (1)

Steve Py
Steve Py

Reputation: 35073

You should avoid using an approach like this because the User will be loaded by one DbContext, while it's orders would be associated to another, disposed context. When you go to update a User, you would be facing errors or duplicate orders, or a messy business of reassociating the order (and other child entities) to contexts before saving. Down the road there will undoubtedly be confusion if orders are mapped to users and someone goes and writes code to .Include(x => x.Orders) If you completely detach related entities from EF and rely on load on demand, you lose out on a lot of the capability that EF gives you.

Issues like this typically stem from mixing up the scope/lifespan of entities vs. the scope of the context they are loaded from. For example loading entities in one method with a DbContext, returning them, then later deciding you want to access related entities but the DbContext was disposed. The simplest method I can recommend using is adopting POCO view models and ensuring that entities never exit the scope of their DbContext, only view models do. That way you can sculpt a view model structure to represent the data you need, then use entities and their references to populate those view models using .Select() without worrying about lazy loading or eager loading.

For instance:

using (var context = new StoreContext())
{
  var userViewModel = context.Users.Where(x => x.UserId == userId)
    .Select(x => new UserViewModel 
    {
      UserId = x.UserId,
      UserName = x.UserName,
      Orders = x.Orders
        .Where(o => o.IsActive)
        .Select( o => new OrderViewModel
        {
          OrderId = o.OrderId,
          OrderNumber = o.OrderNumber
          Price = o.OrderItems.Sum(i => i.Price)
        }).ToList()
     }).SingleOrDefault();
   return userViewModel;
}

Automapper can assist with mapping entities to view models. It's not a one-to-one tree structure map, but rather aligning the view model to represent the data the view needs, then filling that with the entity structure. You just need to be a bit careful to only pull data and supported aggregate methods from the entities because these will be passed to SQL, so no .Net or custom functions in the .Select. Let the view models accept raw values and provide alternate properties to perform formatting, or use .Select() to fetch anonymous types, get EF to materialize those into POCO instances with .ToList()/.Single()/etc. and then populate your view models from those using Linq2Object.

Working with entities on demand and view models / DTOs for the to-and-fro of data avoids a lot of hassle with entities. Done right, EF can pull this data extremely fast and it avoids performance pitfalls such as tripping lazy loads during serialization. It means that when you're done with the View Model you will need to re-load the entity to apply changes. It may seem to make more sense to simply use entities then have EF magically re-attach them and persist changes, but your view model will have all the info needed to quickly fetch that entity by ID if needed, and you will need to consider cases where the data may have changed between the time you first retrieved the entity, and the time you are prepared to alter it.

Upvotes: 2

Related Questions