Introduction

In Entity Framework, you cannot ask EF to load a mapped entity while silently omitting one scalar field from that entity. If you want "everything except one property," the usual solution is projection: select only the columns you need into a DTO, view model, or anonymous type.

Why EF Loads Full Entities

When EF materializes an entity type, it expects a complete shape for the mapped properties it needs to track. That is why a query like context.Documents.FirstAsync() loads all mapped scalar columns for Document, not all columns except one large field you wish to avoid.

Consider this entity:

1public class Document
2{
3    public int Id { get; set; }
4    public string Title { get; set; } = "";
5    public string Author { get; set; } = "";
6    public string Body { get; set; } = "";
7}

If Body contains a large block of text, loading hundreds of rows can become expensive. EF does not offer a query operator that means "load Document but leave Body out." Instead, you change the shape of the result.

Use Projection to Exclude the Field

Projection is the standard approach. Create a lightweight type that contains only the fields you want:

1public class DocumentSummaryDto
2{
3    public int Id { get; set; }
4    public string Title { get; set; } = "";
5    public string Author { get; set; } = "";
6}

Then query into that DTO:

1using Microsoft.EntityFrameworkCore;
2
3var summaries = await context.Documents
4    .Select(d => new DocumentSummaryDto
5    {
6        Id = d.Id,
7        Title = d.Title,
8        Author = d.Author
9    })
10    .ToListAsync();

This produces SQL that selects only the referenced columns. That is usually what people want when they ask how to retrieve an object without one field.

Projection is a good fit when:

• one column is large, such as a blob or long text body
• the UI only needs summary data
• you want to reduce network traffic from the database
• you do not need to update the excluded field in the same query result

Anonymous Types and Read-Only Views

If the result stays inside one method, an anonymous type can be enough:

1var items = await context.Documents
2    .Select(d => new
3    {
4        d.Id,
5        d.Title
6    })
7    .ToListAsync();

That is concise, but the result cannot easily cross method boundaries because the type has no public name. For application code, a DTO or record is usually easier to maintain.

Another practical option is a read model:

public record DocumentListItem(int Id, string Title, string Author);

var listItems = await context.Documents
    .Select(d => new DocumentListItem(d.Id, d.Title, d.Author))
    .ToListAsync();

This keeps the query explicit and makes the intent clear to the next developer.

What to Do When the Field Should Be Separate

If one property is expensive and rarely needed, projection helps, but it may also be a modeling hint. Sometimes the better design is to move the large field into a related table.

For example:

1public class Document
2{
3    public int Id { get; set; }
4    public string Title { get; set; } = "";
5    public string Author { get; set; } = "";
6    public DocumentContent? Content { get; set; }
7}
8
9public class DocumentContent
10{
11    public int DocumentId { get; set; }
12    public string Body { get; set; } = "";
13}

With that design, your list query can load Document rows without loading the related content unless you explicitly include it. This is often better than repeatedly projecting around a single oversized column.

Why Partial Entity Instances Are Risky

Some developers try this:

1var docs = await context.Documents
2    .Select(d => new Document
3    {
4        Id = d.Id,
5        Title = d.Title,
6        Author = d.Author
7    })
8    .ToListAsync();

That creates Document objects, but they are not a safe substitute for fully loaded tracked entities. The missing property can look like a real empty value instead of "not loaded," which becomes dangerous if someone later attaches the entity and saves it.

A dedicated DTO is safer because it makes the incomplete shape obvious.

Common Pitfalls

The biggest mistake is expecting EF to support "entity minus one property" as a built-in feature. For mapped scalar fields, it does not. Use projection or redesign the model.

Another issue is projecting back into the entity type itself. That can confuse later code and create accidental overwrite risks if the partially populated instance is treated like a normal entity.

Do not assume lazy loading will help with scalar properties. Lazy loading applies to navigation properties, not ordinary columns such as string Body.

Finally, if the excluded data is large and frequently causes performance problems, question the schema. A separate table for rarely needed content is often a cleaner long-term solution than repeating custom projections everywhere.

Summary

• EF normally materializes full mapped entities, not "all properties except one."
• Use Select projection to load only the fields you need.
• Prefer DTOs, records, or anonymous types over partial entity instances.
• Split rarely used large fields into a related table when the model calls for it.
• Treat projection as both a performance tool and a way to make intent explicit.