We Keep Coding

EF Core/LINQ - Best solution between Select() and Async Eager Loading?

I wanted to use a Select() method but it seems like Select() doesn't really accept the await keyword. Therefore I was asking myself the question, should I keep using Eager Loading asynchronously or actually the Select method is very good synchronously and will do the job as efficiently as the other ?
I use the Select() to map a very large entity to a DTO and Eager Loading to basically mimic the Select() method by creating a bunch of method including a few relationships such as GetObjectWithPrice and GetObjectWithPriceAndDate and so that's why I was asking for the use of a Select() method instead but the synchronicity worries me.
EDIT
To answer #AvrohomYisroel, here's what I've been doing with my code so far:
public async Task<IReadOnlyList<Book>> GetAllBooksWithRelatedDataAsync()
{
var books = await context.Books
.AsNoTracking()
.AsSplitQuery()
.Include(d => d.Price)
.Include(d => d.Images)
.Include(d => d.Author)
.ToListAsync();
return books;
}
That is how I use Eager Loading asynchronously. And I've been questioning if when using Select(), I was supposed to expect it to be used the same way in terms of asynchronicity. However I might be completely clouded in that the use of Select() is synchronous because it works a different way that I thought it did.

.Select() or projections are generally the most efficient form of data retrieval if performed on the server, but when we use projections we are precluding the use of includes. .Select() will change the shape of the object graph, if you are not changing the shape, then just use .Include(), .AsSplitQuery() gives you the best performance when you need to include related entities because it will load each of the navigation path as an individual query.
.Select() is frequently used in repository patterns to map data models into DTOs, there are other libraries you can use that can simplify this that will internally call .Select().
As of Core 6, LINQ to Entity Projections also support .AsSplitQuery() which means that performance is now less of a concern when choosing between Eager Loading and Projections.
The point of projecting is to pull back not just the required related navigation entities, but only the specific fields that we need. .Select() is therefor an even more eager form of loading than .Include(), but allows for you to be selective about which fields to load.
But we can't have both .Select() and .Include()' in a server expression, in fact any .Include()expressed before the.Select()will be ignored unless the.IQueryable()has been loaded into an.IEnumerable()` first.
As to asynchronicity, there is no difference between .Select() or .Include() if you apply them to an IQueryable<T> expression, the following would still be asynchronous:
var books = await context. Books
.Select(b => new BookDTO {
ISBN = b.BookNumber,
Title = b.Title,
Author = b.Author.Name,
Price = b.Price,
Images = b.Images.Select(i => i.Url)
})
.AsSplitQuery()
.ToListAsync();
The only time that .Select() might constrain you to a synchronous context is if in your projection you have used a function or logic that cannot be converted to a data store (SQL) expression. In this instance EF Core will autmatically evaluate your expression to bring data into memory and then it will perform the .Select(). At that point you are dealing with IEnumerable<T> and synchronous evaluations.

Create EF Core Include().ThenInclude() like function?

I'm writing a few simple extension methods to create DTOs out of entities defined in the domain, however, those entities have properties that are also entities, and I'd like to be able to write something (that I personally find elegant) like they do in EF Core with Include().ThenInclude().
Ideally I'd like to be able to write something like
return myEntity.ToDto().Include(entity => entity.SubEntity).ThenInclude(subEntity => subEntity.AnotherSubEntity);
Is it possible?
The idea is that if I just call ToDto() I would simply receive a basic DTO object where all simple type properties are set but all complex type properties are null, unless I specify that I want to inclue one (or more) of the properties too.

AutoMapper Queryable Extensions provides a convenient way to query entities with relationships and map them to DTOs in one step.
It produces an optimized SQL query needed to copy that data.
Example:
var config = new MapperConfiguration(cfg => {
cfg.CreateMap<BlogDTO, Blog>().ReverseMap();
cfg.CreateMap<PostDTO, Post>().ReverseMap();
});
return _context.Blogs.Where(b => b.Id == Id)
.Include(x => x.Posts)
.ProjectTo<BlogDTO>(config)
.ToList();

I've actually managed to do it by sort of copying how EF Core does it with a lot of reflection and expression trees, and by creating my own visitor to then process the whole expression tree.
I am now able to write code like: myEntity.AsDtoable().Include( x => x.ComplexTypeProp ).ThenInclude( x => x.AnotherComplexTypeProp ).ToDto< EntityDto >();

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.

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.

Include property but exclude one of that property's properties

Let's say I have a method like this in one of my controllers:
[Route("api/Products")]
public IQueryable<Product> GetProducts() {
return db.Products
.Include(p => p.Category);
}
Using this I can get a product from the database and include its Category property.
In my CategoryControllerI have this method:
[Route("api/Categories")]
public IQueryable<Category> GetCategories() {
return db.Categories
.Include(c => c.Parent)
.Include(c => c.Products)
.Include(c => c.SubCategories);
}
When I send a GET request to the CategoryController this works as intended, I get the category, its parent, its products and its sub-categories. But when I send a GET request to the ProductController I don't want to include all the products in the category of the requested product, I just need the basic information about that category.
So, how can I make GetProducts() return the products in the database, including the Category property of each product, but excluding the Products list property of the category, still keeping the other properties like id, title and so on?
Thank you.

As said in the comments, the first step is to disable lazy loading. You can either do that by removing the virtual modifier from the collection properties, which is permanent, or by disabling it per context instance, which is temporary:
context.Configuration.ProxyCreationEnabled = false;
(disabling proxy creation also disables lazy loading, but keeps the generated objects more light-weight).
In disconnected scenarios, like web API, people often prefer to disable lazy loading by default, because of this serializer-lazy-loading cascade.
However, you can't stop Entity Framework from executing relationship fixup. Loading a Productattaches it to the context. Include()-ing its categories attaches those to the context and EF populates their Products collections with the attached product, whether you like it or not. Circular references will still be a problem.
You can somewhat reduce this effect by fetching the products with AsNoTracking (which prevents entities to get attached, i.e. change-tracked):
return db.Products.AsNoTracking()
.Include(p => p.Category);
Now categories will only have their Products filled with the Product of which they are the category.
By the way, in disconnected scenarios, also using AsNoTracking is preferred. The entities won't ever be saved by the same context instance anyway and it increases performance.
Solutions
Return DTOs, not entity types
By using DTO objects you take full control over the object graph that will be serialized. Lazy loading won't surprise you. But yeah, the amount of required DTO classes can be overwhelming.
Return anonymous types.
This will raise some eyebrows because we should never return anonymous types from methods, right? Well, they leave an action method as a Json string, just as named types, and the javascript client doesn't know the distinction. You might say that it only brings the weakly typed javascript environment one step closer. The only thing is that a named DTO type serves as a data contract (of sorts) and anonymous types can be changed (too) easily and break client-side code.
Tweak the serializer.
You can tell the Json.Net serializer to ignore reference loops. Using JsonConvert directly, it looks like so:
var products = db.Products.AsNoTracking().Include(p => p.Category);
var setting = new JsonSerializerSettings
{
Formatting = Newtonsoft.Json.Formatting.Indented, // Just for humans
ReferenceLoopHandling = ReferenceLoopHandling.Ignore
};
var json = JsonConvert.SerializeObject(products, setting);
In combination with AsNoTracking() this will serialize the categories with empty Products arrays ("Products": []), because Product - Category - Product is a reference loop.
In Web API there are several ways to configure the built-in Json.Net serializer, you may want to do this per action method.
Personally, I prefer using DTOs. I like to be in control (also over the properties that cross the wire) and I don't particularly like to rely on a serializer to solve for me what I neglected to do.

I believe it's not the best practice but it will work, you could create new object and fill it.
[Route("api/Products")]
public IQueryable<Product> GetProducts() {
return db.Products
.Include(p => p.Category);
.Select(x => new Product{
Name = x.Name,
Price = x.Price,
Category = new Category{
Name = x.Category.Name}})
}

Automapper, MapFrom and EF dynamic proxies

I have been trying to map my domain objects to a report view model. Things all worked well in testing where I faked the entity framework code out and used a builder to return a fully populated pocco object. Now that I am actually hitting the database and returning data I am seeing some wierd dynamic proxy type errors.
Here is a sample of my code:
public class ContactMapping : Profile
{
protected override void Configure()
{
Mapper.CreateMap<Contact, ReportRowModel>()
.ForMember(dest => dest.Gender, opt => opt.MapFrom(src => src.Gender.Name));
}
}
And the mapping code is like this:
var contact = GetContactFor(clientPolicy);
Mapper.DynamicMap(contact, rowModel);
return rowModel;
The contact fields all populate correctly except for the rowModel.Gender field which is returning System.Data.Entity.DynamicProxies.Gender_3419AAE86B58120AA2983DA212CFFEC4E42296DA14DE0836B3E25D7C6252EF18
I have seen solutions where people have had problems using Map instead of DynamicMap, but I haven't found anything where a .ForMember mapping is failing like this.
Any suggestions.

Your EF query is not returning the Gender, it is returning a Proxy that can get Gender for you when evaluated, which is not of the type that AutoMapper built a mapping to handle.
You either need to eagerly fetch Gender in your query, or use AutoMapper's IQueryable Extention's Project method to have AutoMapper emit an anonymous projection (again, in your query), rather than try to apply the AutoMapping after the result has been returned from your EF context.
This is good practice in general to avoid Select N+1 issues.

I've got the same issue right now with version 4.x, reverting to 3.3.1 fixed the issue.