Table of Contents

Introduction
1. Revisiting Include(): A Quick Refresher
▹ Loading a book together with its publisher
▹ Does every query need Include()?
2. Understanding EF Core Data-Loading Strategies
▹ Eager loading: Retrieve related data with the main query
▹ Explicit loading: Retrieve related data when needed
▹ Lazy loading: Convenient, but easy to misuse
3. Moving Beyond Basic Queries with LINQ
▹ Filtering records in the database
▹ Combining conditions with related data
▹ Counting records without loading them all
▹ Grouping data for summaries
4. Building More Efficient Queries in Blazor
▹ Use Projection to Retrieve Only the Data You Need
▹ Use AsNoTracking() for Read-Only Queries
▹ Combine Filtering, Projection, and No-Tracking
▹ Apply These Techniques in Blazor
5. Inspecting the SQL Generated by EF Core
▹ Why You Should Inspect Generated SQL
▹ Using ToQueryString()
▹ Understanding the SQL Output
6. Complete Runnable Books.razor
▹ A. Understanding @inject ILogger Logger
▹ B. Understanding errorMessage
▹ C. Understanding isLoading
▹ D. How These Three Pieces Work Together
▹ E. Test It in Visual Studio
Conclusion
References

Introduction

Imagine that you are building a library application with Blazor and Entity Framework Core. The application can display books, show their publishers, and save changes to SQL Server. Everything works as expected.

Then the library grows from a few dozen books to several thousand. A page that once loaded almost instantly starts taking longer. Some operations retrieve more data than the screen needs, while others make repeated trips to the database.

The application may still be correct. The problem is how it retrieves its data.

This is an important stage in learning Entity Framework Core (EF Core). Creating, reading, updating, and deleting records is only the beginning. A well-designed application must also retrieve the right data, avoid unnecessary database operations, and handle related entities deliberately.

In Article 4 of this series, we explored the one-to-many relationship between publishers and books, including navigation properties, Fluent API configuration, and retrieving related data with Include().

Now, we can build on that foundation. This article explores EF Core data-loading strategies, LINQ projections, aggregation, read-only queries, and generated SQL. We will apply these concepts to the same Blazor library application, using SQL Server as the database.

The goal is not to make every query complicated. It is to make each query fit the job it needs to perform.

1. Revisiting Include(): A Quick Refresher

In our library application, a book can belong to a publisher. The Book entity contains a foreign key and a navigation property:

namespace LibraryEfCore.Data.Models;

public class Book
{
   public int Id { get; set; }
   public string Title { get; set; } = "";
   public string? ISBN { get; set; }
   public short PublishedYear { get; set; }
   public string? Description { get; set; }

   // Foreign Key & Navigation Property
   public short? PublisherId { get; set; }
   public Publisher? Publisher { get; set; }
}

The PublisherId property identifies the associated publisher. The Publisher navigation property allows application code to work with the related publisher entity when it has been loaded.

These two properties serve different purposes. A foreign key identifies a relationship in the database, while a navigation property provides an object-oriented way to access related data.

Loading a book together with its publisher

Suppose we want to display a list of books with their publisher names. We can use Include():

var books = await db.Books
    .Include(b => b.Publisher)
    .ToListAsync();

This is an example of eager loading. We tell EF Core that the related publisher data is needed as part of the query.

The result can then be used in a Razor component:

@foreach (var book in books)
{
    <tr>
        <td>@book.Title</td>
        <td>@(book.Publisher?.Name ?? "Not assigned")</td>
    </tr>
}

The null-conditional operator (?.) is useful here because the publisher relationship is optional. A book may not have a publisher assigned.

Does every query need Include()?

No. Include() is useful when you need related entity objects, but it is not required merely because a relationship exists.

For example, if a page needs only the book title and publisher name, you can select those values directly. You do not necessarily need to load complete Book and Publisher entities.

That distinction leads to a useful rule:

• Use Include() when you need related entities.
• Consider projection when you need only selected values from those entities.

The best choice depends on what the application will do with the results.

2. Understanding EF Core Data-Loading Strategies

EF Core supports several approaches to loading related data. Understanding their differences helps you choose a strategy that fits each operation.

Eager loading: Retrieve related data with the main query

Eager loading is the approach we have already seen:

var books = await db.Books
    .Include(b => b.Publisher)
    .ToListAsync();

It is appropriate when the page needs the book and publisher information together.

For example, a library catalog might display a table containing book titles, ISBNs, publication years, and publisher names. Retrieving the required information as part of the initial query makes the data requirements explicit.

Eager loading does not guarantee that EF Core will always execute exactly one SQL statement. Depending on the query and configuration, EF Core can use a single query or split the work into multiple queries.

For a simple reference navigation such as Book.Publisher, a join is a common translation. More complicated collection-loading queries can introduce different performance considerations.

Explicit loading: Retrieve related data when needed

Sometimes, an application does not need related data immediately. Imagine a library administrator opens a book’s detail page. The page initially displays the title and publication year. The administrator can then select a button to display additional publisher information.

In that situation, explicit loading may be appropriate:

var book = await db.Books
    .FirstOrDefaultAsync(b => b.Id == bookId);

if (book is not null)
{
    await db.Entry(book)
        .Reference(b => b.Publisher)
        .LoadAsync();
}

This example assumes that bookId contains the requested book's ID and that db is an active LibraryDbContext.

The second operation explicitly loads the publisher navigation property. It requires another database operation if the relationship has not already been loaded.

That extra round trip may be worthwhile when the related information is genuinely optional. If every page request needs the publisher name, eager loading or projection is usually simpler.

Lazy loading: Convenient, but easy to misuse

Lazy loading retrieves related data when a navigation property is accessed, provided the feature has been configured and the entity supports it.

For example, code that accesses book.Publisher might trigger a database query automatically. This convenience can hide an important cost: the application may execute many more queries than the code appears to contain.

Suppose a page loads 100 books and then accesses each book’s publisher individually. With lazy loading, this can result in one query for the books and additional queries for their publishers.

This pattern is commonly called the N+1 query problem: one query retrieves the main collection, and additional queries retrieve related data for individual items.

The exact number of queries depends on factors such as which relationships are accessed and whether related entities have already been loaded or tracked. Even so, the risk is worth understanding.

For our learning project, explicit query design with eager loading or projection is a good starting point. It makes database access easier to reason about and avoids introducing lazy-loading behavior that can surprise beginners.

3. Moving Beyond Basic Queries with LINQ

LINQ allows us to describe what data we want using C#. EF Core translates supported expressions into database operations when the query is executed.

We do not need to retrieve an entire table simply because we want to work with its records.

Filtering records in the database

Suppose the library catalog should display only books published from 2020 onward. We can write:

var books = await db.Books
    .Where(b => b.PublishedYear >= 2020)
    .ToListAsync();

The Where() condition becomes part of the database query when EF Core can translate it. SQL Server can then filter the records before returning the results to the application.

This is generally preferable to retrieving every book and filtering the collection afterward:

// Avoid this when the filtering can be done in SQL.
var allBooks = await db.Books.ToListAsync();

var recentBooks = allBooks
    .Where(b => b.PublishedYear >= 2020)
    .ToList();

The second version transfers all books to the application before filtering them in memory. For a small demonstration, the difference might be negligible. For a large database, it can waste memory, network bandwidth, and processing time.

There is also a practical distinction between IQueryable<T> and IEnumerable<T>. An EF Core query normally remains an IQueryable<T> while you compose database-translatable operations. Calling ToListAsync() executes the query and materializes the results into a list.

Combining conditions with related data

Now suppose we want to retrieve books published from 2020 onward and display their publishers. We can combine filtering with eager loading:

var books = await db.Books
    .Where(b => b.PublishedYear >= 2020)
    .Include(b => b.Publisher)
    .ToListAsync();

The query describes two requirements:

• Return books whose publication year is at least 2020.
• Load the associated publisher for each returned book.

EF Core can translate these requirements into SQL. The database performs the filtering, while the related publisher data is retrieved according to the loading strategy.

Notice that the query remains readable. We do not need to write SQL manually for every common data-access operation.

Counting records without loading them all

What if the page needs to show the number of books in the catalog? We could retrieve every book and count the resulting list, but that would be unnecessary. Instead, use CountAsync():

var bookCount = await db.Books.CountAsync();

To count only recently published books:

var recentBookCount = await db.Books
    .CountAsync(b => b.PublishedYear >= 2020);

EF Core translates these operations into database-side counting when supported. SQL Server can return the count without transferring every matching book row to the application.

Other useful aggregate operations include AnyAsync(), SumAsync(), AverageAsync(), MinAsync(), and MaxAsync(), where appropriate for the data being queried.

For example, to determine whether a publisher has any books:

var hasBooks = await db.Books
    .AnyAsync(b => b.PublisherId == publisherId);

This is clearer than loading the publisher’s entire collection just to determine whether at least one book exists.

Grouping data for summaries

A library dashboard might need to show how many books each publisher has published. We can use GroupBy() and Select():

var publisherSummaries = await db.Books
    .GroupBy(b => b.PublisherId)
    .Select(g => new
    {
        PublisherId = g.Key,
        BookCount = g.Count()
    })
    .ToListAsync();

This groups books by their publisher foreign key and calculates a count for each group. Because PublisherId is nullable, the results may include a group for books that have no publisher assigned.

This example illustrates the principle of aggregation, but it returns publisher IDs rather than publisher names. If the dashboard needs names too, we can write a projection that joins publishers and groups the results, or query the publishers with a count of their related books.

For instance, a publisher-oriented summary can be written as:

var publisherSummaries = await db.Publishers
    .Select(p => new
    {
        p.Name,
        BookCount = p.Books.Count()
    })
    .ToListAsync();

EF Core can translate supported collection-count expressions into database queries. As always, inspect the generated SQL if performance or translation behavior is uncertain.

4. Building More Efficient Queries in Blazor

As your library application grows, retrieving data efficiently becomes increasingly important. A query that works well with a few dozen books may become less efficient when the database contains thousands of records. Fortunately, Entity Framework Core provides several techniques to help you retrieve only the data you need and reduce unnecessary processing.

In this section, we will explore four practical techniques: projection, no-tracking queries, combining query operations, and applying these techniques in a Blazor component.

Use Projection to Retrieve Only the Data You Need

When you query an entity, EF Core can retrieve all the mapped columns for that entity, even if your page displays only a few of them. Projection allows you to select only the properties required by your application.

For example, suppose your library catalog displays only a book’s title and publication year. You could retrieve the complete Book entities:

var books = await db.Books
    .ToListAsync();

However, this query retrieves all mapped columns for each book. If the Book entity contains properties such as Description, ISBN, and PublisherId, those columns may be retrieved even when the page does not need them.

A more focused query uses Select():

var books = await db.Books
    .Select(b => new
    {
        b.Title,
        b.PublishedYear
    })
    .ToListAsync();

Here, Select() projects each result into an anonymous object containing only Title and PublishedYear. EF Core can translate this projection into SQL that selects only the corresponding columns.

For example, the generated SQL may resemble:

SELECT [b].[Title], [b].[PublishedYear]
FROM [Books] AS [b];

The exact SQL formatting and aliases may vary depending on the EF Core version and query configuration.

Projection is particularly useful when building tables, summary cards, reports, and dashboard components. It can reduce the amount of data transferred from SQL Server and avoid materializing complete entities when only a few values are required.

For larger applications, you can project into a dedicated class instead of an anonymous type:

public class BookListItem
{
    public string Title { get; set; } = "";
    public int PublishedYear { get; set; }
}

Then use the class in your query:

var books = await db.Books
    .Select(b => new BookListItem
    {
        Title = b.Title,
        PublishedYear = b.PublishedYear
    })
    .ToListAsync();

This approach makes the result structure explicit and reusable. It is especially helpful when passing data between application layers or displaying results in a Blazor component.

Use AsNoTracking() for Read-Only Queries

By default, EF Core tracks changes to entity instances returned by many queries. This tracking allows EF Core to detect modifications and persist them when you call SaveChangesAsync().

Change tracking is useful when you intend to update an entity. However, it may introduce unnecessary overhead when a page only displays data and does not modify the retrieved entities.

Consider a page that lists every book in the library:

var books = await db.Books
    .OrderBy(b => b.Title)
    .ToListAsync();

If the page only displays these books, tracking their changes is generally unnecessary. You can use AsNoTracking() to tell EF Core not to track the returned entities:

var books = await db.Books
    .AsNoTracking()
    .OrderBy(b => b.Title)
    .ToListAsync();

This option can reduce memory usage and change-tracking overhead, particularly when retrieving many entities. However, the actual performance benefit depends on the query, the number of results, and the application’s workload.

There is one important distinction: AsNoTracking() does not prevent you from reading or displaying the results. It simply means EF Core will not track the returned entities in its change tracker. If you later modify one of those entities and call SaveChangesAsync(), EF Core will not automatically persist that modification unless you explicitly attach or otherwise track the entity.

Use tracking queries when you need to load entities, modify them, and save the changes through the same context. Use no-tracking queries when you only need to retrieve and display entity data.

Combine Filtering, Projection, and No-Tracking

The techniques above are useful individually, but they can also be combined in a single query. This allows you to filter records, select specific properties, and avoid tracking entity results when appropriate.

Suppose your library application allows users to select a publisher and view only that publisher’s books. The page needs each book’s title and publication year, but it does not need the complete Book entity.

You could write:

var books = await db.Books
    .AsNoTracking()
    .Where(b => b.PublisherId == publisherId)
    .OrderBy(b => b.Title)
    .Select(b => new BookListItem
    {
        Title = b.Title,
        PublishedYear = b.PublishedYear
    })
    .ToListAsync();

This query combines four operations:

• AsNoTracking() specifies that returned entity instances should not be tracked.
• Where() filters the books by publisher.
• OrderBy() sorts the results alphabetically by title.
• Select() projects each result into a BookListItem containing only the required properties.

EF Core translates the query into SQL and executes it when ToListAsync() is called. Filtering, sorting, and selecting columns can therefore be performed by SQL Server rather than by retrieving all books and processing them in application memory.

Notice that the final result consists of BookListItem objects, not Book entities. Since this projection does not return Book entity instances, EF Core does not track the Book entities in this example anyway. Consequently, AsNoTracking() is not essential for this particular projection, although including it can make the read-only intention explicit and keep the query style consistent.

This distinction matters: projection and no-tracking solve related but different problems. Projection controls the shape of the returned data, while no-tracking controls whether EF Core tracks returned entity instances.

Apply These Techniques in Blazor

Let’s apply these ideas to the library application. Imagine a Blazor page that displays a list of books and lets users filter the results by publisher.

For this page, we want to:

1. Retrieve the publisher names for a dropdown list.
2. Display only the book properties needed by the table.
3. Filter the books when a publisher is selected.
4. Sort the results by title.
5. Avoid unnecessary entity tracking for read-only operations.

A query for the publisher dropdown could look like this:

var publishers = await db.Publishers
    .AsNoTracking()
    .OrderBy(p => p.Name)
    .Select(p => new PublisherOption
    {
        Id = p.Id,
        Name = p.Name
    })
    .ToListAsync();

The PublisherOption class can be defined as follows:

public class PublisherOption
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
}

This query retrieves only the publisher ID and name, which are sufficient for displaying dropdown options. Because the result is a projection into PublisherOption, the query does not return tracked Publisher entities.

Next, the page can retrieve books based on the selected publisher:

var query = db.Books.AsNoTracking();

if (selectedPublisherId.HasValue)
{
    query = query.Where(
        b => b.PublisherId == selectedPublisherId.Value);
}
var books = await query
    .OrderBy(b => b.Title)
    .Select(b => new BookListItem
    {
        Title = b.Title,
        Description = b.Description,
        ISBN = b.ISBN,
        PublishedYear = b.PublishedYear,
        PublisherName = b.Publisher != null
            ? b.Publisher.Name
            : "Not assigned"
    })
    .ToListAsync();

Here, selectedPublisherId is a nullable integer. When it has a value, the query filters the books by publisher. When it is null, the query returns books from all publishers.

The projection also retrieves the publisher’s name through the Publisher navigation property. EF Core can translate this expression into the appropriate SQL, so you do not need to call Include() simply to display the publisher's name. The result is a list of BookListItem objects containing the values needed by the page.

The corresponding result class is:

public class BookListItem
{
    public string Title { get; set; } = "";
    public string? Description { get; set; }
    public string? ISBN { get; set; }
    public int PublishedYear { get; set; }
    public string PublisherName { get; set; } = "";
}

Because this is a projection into a class rather than a collection of Book entities, EF Core does not track the Book entities for this query. The AsNoTracking() call is therefore optional in this specific example; it is more directly useful for queries that return entity instances.

In a Blazor Interactive Server application, you should also manage the lifetime of DbContext carefully. One common approach is to use IDbContextFactory<LibraryDbContext> to create a context for each database operation:

await using var db =
    await DbFactory.CreateDbContextAsync();

var books = await db.Books
    .AsNoTracking()
    .OrderBy(b => b.Title)
    .Select(b => new BookListItem
    {
        Title = b.Title,
        PublishedYear = b.PublishedYear
    })
    .ToListAsync();

This example assumes that DbFactory has been injected into the component and registered in Program.cs. Creating and disposing a context for each operation helps prevent a long-lived context from being shared across unrelated component operations.

These techniques provide a practical foundation for efficient data retrieval in Blazor. By selecting only the required properties, choosing tracking behavior deliberately, and letting SQL Server handle filtering and sorting, you can keep your queries focused as the library grows.

5. Inspecting the SQL Generated by EF Core

When you write queries with Entity Framework Core, you work primarily with C# and LINQ rather than SQL statements. EF Core translates supported LINQ expressions into SQL that the database provider can execute. This abstraction makes database programming more convenient, but understanding the SQL generated by EF Core is still an important skill.

Inspecting the generated SQL helps you understand how your LINQ queries interact with SQL Server. It can also reveal whether a query retrieves unnecessary columns, applies filtering in the database, or produces joins that deserve closer examination. In this section, we will explore why generated SQL matters, how to inspect it using ToQueryString(), and how to interpret the resulting SQL.

Why You Should Inspect Generated SQL

Two LINQ queries may produce the same results while generating different SQL statements. Depending on the query structure, one approach may retrieve more data than necessary or introduce additional database operations.

For example, consider this query:

var books = await db.Books
    .ToListAsync();

This query retrieves all mapped columns for all books. If your page displays only the title and publication year, retrieving every mapped column may be unnecessary.

Compare it with a projected query:

var books = await db.Books
    .Select(b => new
    {
        b.Title,
        b.PublishedYear
    })
    .ToListAsync();

The second query requests only the two required columns. Inspecting its generated SQL allows you to verify that EF Core translates the projection as expected.

Examining SQL can help you investigate several questions:

• Does the query retrieve only the columns the page needs?
• Is filtering performed by SQL Server or unnecessarily in application memory?
• Does the query introduce joins to retrieve related data?
• Are sorting and aggregation operations translated into SQL?
• Could the query retrieve more records than the application actually needs?

Generated SQL is not a complete measure of query performance. A short SQL statement can still perform poorly because of indexes, data distribution, execution plans, or other database conditions. Nevertheless, inspecting the SQL is a useful first step toward understanding and improving database access.

Using ToQueryString()

EF Core provides the ToQueryString() extension method to display a debugging representation of the SQL for an IQueryable. You can use it to inspect the SQL generated from a LINQ query without first executing that query.

Suppose you want to retrieve books published in or after 2020, sorted alphabetically by title:

var query = db.Books
    .Where(b => b.PublishedYear >= 2020)
    .OrderBy(b => b.Title)
    .Select(b => new
    {
        b.Title,
        b.PublishedYear
    });

var sql = query.ToQueryString();
Console.WriteLine(sql);

Make sure your file includes the EF Core namespace:

using Microsoft.EntityFrameworkCore;

The ToQueryString() method returns a string containing the SQL representation of the query. For SQL Server, the output may resemble the following:

SELECT [b].[Title], [b].[PublishedYear]
FROM [Books] AS [b]
WHERE [b].[PublishedYear] >= 2020
ORDER BY [b].[Title]

The exact output may differ depending on your EF Core version, provider, and model configuration.

Notice that the SQL contains only the two requested columns. The publication-year condition appears in the WHERE clause, and the title ordering appears in the ORDER BY clause. This shows how EF Core translates the corresponding LINQ operations into SQL.

You can also inspect a query that retrieves a book’s publisher name:

var query = db.Books
    .Where(b => b.PublisherId != null)
    .Select(b => new
    {
        b.Title,
        PublisherName = b.Publisher!.Name
    });

Console.WriteLine(query.ToQueryString());

Because the query accesses the publisher’s name through a navigation property, EF Core can generate a SQL join to retrieve the related data. The exact SQL depends on the relationship configuration and the expression being translated.

An important distinction: ToQueryString() is intended for debugging and inspection. It does not execute the query, and its output is not guaranteed to be the exact final command sent to the database in every situation. For example, the actual command may differ when EF Core applies execution-time behavior or when the query is used in a context that changes its translation.

To see the results, you must still execute the query:

var books = await query.ToListAsync();

In a Blazor application, you can inspect the returned SQL while debugging, use a breakpoint to examine the sql variable, or write the output to your application's logging system. Avoid relying on Console.WriteLine() as your primary production logging mechanism.

Understanding the SQL Output

Being able to display generated SQL is useful, but the next step is learning how to interpret it. You do not need to become a SQL Server expert immediately. Start by connecting familiar LINQ operations with their SQL equivalents.

Consider this query:

var query = db.Books
    .Where(b => b.PublishedYear >= 2020)
    .OrderBy(b => b.Title)
    .Select(b => new
    {
        b.Title,
        b.PublishedYear
    });

Its generated SQL may resemble:

SELECT [b].[Title], [b].[PublishedYear]
FROM [Books] AS [b]
WHERE [b].[PublishedYear] >= 2020
ORDER BY [b].[Title]

Each part corresponds to an operation in the LINQ query:

LINQ operationSQL equivalentPurposeSelect()SELECTChooses the columns returnedWhere()WHEREFilters recordsOrderBy()ORDER BYSorts the resultsToListAsync()Executes the queryRetrieves the results from the database

The last row requires a small clarification: ToListAsync() is the operation that triggers execution of this query, not a SQL clause in the generated statement.

When inspecting generated SQL, look for a few practical details.

1. Check which columns are selected.

If your page needs only a book’s title and publication year, the SQL should generally select only those columns. If it retrieves a large description field or other unnecessary columns, consider whether projection would help.

2. Check where filtering happens.

A condition expressed through a translatable LINQ Where() operation will normally appear in the SQL WHERE clause. This allows SQL Server to filter records before returning the results to your application. Avoid retrieving an entire table and filtering it in C# when the database can perform the filtering.

3. Examine joins when accessing related data.

If your query selects b.Publisher.Name, EF Core may generate a join between the Books and Publishers tables. This is often appropriate, but you should understand which related data the query needs. Selecting a related property does not necessarily require loading the entire related entity.

4. Look for unnecessary result sets or excessive data retrieval.

If a page displays a small subset of records, retrieving every record may be inefficient. Consider filtering, pagination, or a more targeted projection. The best solution depends on the page’s requirements.

5. Remember that generated SQL is only part of performance analysis.

Even SQL that looks reasonable can run slowly if the database has unsuitable indexes, large volumes of data, or an expensive execution plan. For deeper investigation, SQL Server execution plans and database performance tools provide additional information.

The goal is not to inspect every SQL statement in every application. Rather, use ToQueryString() when learning EF Core, investigating unexpected query behavior, or diagnosing a performance concern. It gives you a practical way to connect your C# code with the SQL that EF Core generates.

By understanding both LINQ and its SQL translation, you can make more informed decisions about query design and build Blazor applications that access SQL Server more efficiently.

6. Complete Runnable Books.razor

The example below includes publisher filtering, asynchronous database access, loading and error states, and the Description field from your existing Book model.

@page "/books"
@using Microsoft.EntityFrameworkCore
@using LibraryEfCore.Data
@using Microsoft.JSInterop
@inject IJSRuntime JS
@inject IDbContextFactory<LibraryDbContext> DbFactory
@inject ILogger<Books> Logger

<PageTitle>Books</PageTitle>
<h1>Library Catalog</h1>
<p>
   Browse the books in the library and filter them by publisher.
</p>
<p>
   <a class="btn btn-primary" href="/books/add">
        Add Book
   </a>
</p>

<div class="mb-3 d-flex align-items-center gap-3">
   <label for="publisherFilter"
      class="form-label mb-0 text-nowrap">
      Filter by publisher
   </label>

   <select id="publisherFilter"
           class="form-select"
           value="@PublisherFilterValue"
           @onchange="OnPublisherChangedAsync"
           disabled="@isLoading">

      <option value="">All publishers</option>
      @foreach (var publisher in publishers)
      {
         <option value="@publisher.Id">
            @publisher.Name
         </option>
      }
   </select>
</div>

@if (isLoading)
{
   <p>Loading books...</p>
}
else if (!string.IsNullOrWhiteSpace(errorMessage))
{
   <div class="alert alert-danger" role="alert">
      @errorMessage
   </div>

   <button type="button"
           class="btn btn-primary"
           @onclick="LoadCatalogAsync">
      Try Again
   </button>
}
else if (books.Count == 0)
{
   <p>No books have been added yet.</p>
}
else
{
   <p>
      Books found: <strong>@books.Count</strong>
   </p>

   <table class="table">
      <thead>
         <tr>
            <th>Title</th>
            <th>ISBN</th>
            <th>Publisher</th>
            <th>Published Year</th>
            <th>Description</th>
            <th>Actions</th>
         </tr>
      </thead>
      <tbody>
         @foreach (var book in books)
         {
            <tr>
               <td>@book.Title</td>
               <td>@(book.ISBN ?? "-")</td>
               <td>@(book.PublisherName ?? "Not assigned")</td>
               <td>@book.PublishedYear</td>
               <td>@(book.Description ?? "-")</td>
               <td>
                  <a class="btn btn-sm btn-primary me-1 mt-1"
                     href="@($"/books/edit/{book.Id}")">
                     Edit
                  </a>
                  <button class="btn btn-sm btn-danger mt-1"
                     @onclick="() => DeleteBookAsync(book.Id)">
                     Delete
                  </button>
               </td>
            </tr>
         }
      </tbody>
   </table>
}

@code {
   private List<PublisherOption> publishers = new();
   private List<BookListItem> books = new();
   private int? selectedPublisherId;
   private bool isLoading;
   private string? errorMessage;
   private string PublisherFilterValue =>
      selectedPublisherId?.ToString() ?? "";

   protected override async Task OnInitializedAsync()
   {
      await LoadCatalogAsync();
   }

   private async Task LoadCatalogAsync()
   {
      isLoading = true;
      errorMessage = null;

      try
      {
         await LoadPublishersCoreAsync();
         await LoadBooksCoreAsync();
      }
      catch (Exception ex)
      {
         Logger.LogError(
             ex,
             "Failed to load the library catalog.");

         errorMessage =
             "Unable to load the library catalog. " +
             "Check the database connection and try again.";
      }
      finally
      {
         isLoading = false;
      }
   }

   private async Task LoadPublishersCoreAsync()
   {
      await using var db =
         await DbFactory.CreateDbContextAsync();

      publishers = await db.Publishers
         .AsNoTracking()
         .OrderBy(p => p.Name)
         .Select(p => new PublisherOption
         {
            Id = p.Id,
            Name = p.Name
         })
         .ToListAsync();
   }

   private async Task OnPublisherChangedAsync(
       ChangeEventArgs args)
   {
      var value = args.Value?.ToString();

      selectedPublisherId =
         int.TryParse(value, out var publisherId)
            ? publisherId
            : null;

      await LoadBooksAsync();
   }

   private async Task LoadBooksAsync()
   {
      isLoading = true;
      errorMessage = null;

      try
      {
         await LoadBooksCoreAsync();
      }
      catch (Exception ex)
      {
         Logger.LogError(
            ex,
            "Failed to load books for publisher {PublisherId}.",
            selectedPublisherId);

         errorMessage =
            "Unable to load books. " +
            "Check the database connection and try again.";
      }
      finally
      {
         isLoading = false;
      }
   }

   private async Task LoadBooksCoreAsync()
   {
      await using var db =
         await DbFactory.CreateDbContextAsync();

      var query = db.Books.AsNoTracking();

      if (selectedPublisherId.HasValue)
      {
         query = query.Where(
            b => b.PublisherId == selectedPublisherId.Value);
      }

      books = await query
         .OrderBy(b => b.Title)
         .Select(b => new BookListItem
         {
            Id = b.Id,
            Title = b.Title,
            Description = b.Description,
            ISBN = b.ISBN,
            PublishedYear = b.PublishedYear,
            PublisherName = b.Publisher != null
               ? b.Publisher.Name
               : "Not assigned"
         })
         .ToListAsync();
   }

   private async Task DeleteBookAsync(int id)
   {
      var confirmed = await JS.InvokeAsync<bool>(
         "confirm",
         "Are you sure you want to delete this book?");

      if (!confirmed)
      {
         return;
      }

      isLoading = true;
      errorMessage = null;

      try
      {
         await using var db =
            await DbFactory.CreateDbContextAsync();

         var book = await db.Books.FindAsync(id);

         if (book is null)
         {
            errorMessage =
               "The book could not be found. " +
               "The catalog will be refreshed.";

            await LoadBooksCoreAsync();
            return;
         }

         db.Books.Remove(book);
         await db.SaveChangesAsync();

         // Refresh the catalog after deletion.
         await LoadBooksCoreAsync();
      }
      catch (Exception ex)
      {
         Logger.LogError(
            ex,
            "Failed to delete book with ID {BookId}.",
            id);

         errorMessage =
            "Unable to delete the book. " +
            "The database may be unavailable, " +
            "or the book may be referenced by another record.";
      }
      finally
      {
         isLoading = false;
      }
   }

   private sealed class PublisherOption
   {
      public int Id { get; set; }
      public string Name { get; set; } = "";
   }

   private sealed class BookListItem
   {
      public int Id { get; set; }
      public string Title { get; set; } = "";
      public string? Description { get; set; }
      public string? ISBN { get; set; }
      public int PublishedYear { get; set; }
      public string PublisherName { get; set; } = "";
   }
}

A. Understanding @inject ILogger<Books> Logger

@inject ILogger<Books> Logger

This directive injects an instance of ILogger<Books> into the Books Razor component. Logging is a built-in feature of ASP.NET Core that allows an application to record information about its execution, including warnings, errors, and diagnostic details.

Let’s break down the declaration:

• @inject is a Razor directive that makes a service available to the component through dependency injection.
• ILogger<Books> is a logging service associated with the Books component. The generic type Books identifies the category used for log messages, making it easier to determine which component produced a message.
• Logger is the variable name used to access the logging service in the component's C# code.

For example, the following statement records an error when loading the library catalog fails:

catch (Exception ex)
{
    Logger.LogError(
        ex,
        "Failed to load the library catalog.");

errorMessage =
        "Unable to load the library catalog. " +
        "Check the database connection and try again.";
}

The call to Logger.LogError() records the exception and its details through the configured logging providers. During development, these details can help you investigate problems such as database connection failures, SQL errors, or unexpected application exceptions.

Notice that the application also assigns a message to errorMessage. This message is intended for the user, whereas the log entry is intended primarily for developers and administrators.

Why use both?

Displaying the full exception to users is generally undesirable because technical details may be confusing and could reveal sensitive implementation information. Logging the exception preserves diagnostic information without exposing it directly in the interface.

ASP.NET Core provides logging infrastructure by default, so you do not need to install an additional logging package for this example.

B. Understanding errorMessage

In the Books.razor component, we declare:

private string? errorMessage;

This declaration creates a private field that stores an error message to be displayed when a database operation fails.

Let’s examine its parts:

• private means the field is accessible only within the component's C# code.
• string specifies that the field stores text.
• ? indicates that the string may be null.
• errorMessage is the field's name.

Because the field is not initialized explicitly, its initial value is null. This is appropriate because no error message is needed when the page first loads successfully.

How is errorMessage used?

Consider this Razor markup:

@if (!string.IsNullOrWhiteSpace(errorMessage))
{
    <div class="alert alert-danger" role="alert">
        @errorMessage
    </div>
}

The expression string.IsNullOrWhiteSpace(errorMessage) checks whether the string is null, empty, or contains only whitespace. The ! operator reverses the result, so the block is rendered only when a meaningful error message exists.

For example, if a database operation fails, the component can assign:

errorMessage =
    "Unable to load the library catalog. " +
    "Check the database connection and try again.";

Blazor then renders the message inside a Bootstrap alert element. The alert alert-danger classes give the message the familiar red error styling, while role="alert" helps assistive technologies recognize the message as an alert.

When the operation starts again, the component clears the previous message:

errorMessage = null;

This prevents an old error from remaining visible after a new attempt begins.

How does this relate to Blazor rendering?

Blazor components automatically render again when their event handlers or lifecycle methods update component state in the normal Blazor execution flow. Therefore, when errorMessage changes during an event handler, the component can update its displayed markup without manually manipulating the DOM.

This is an important difference from traditional JavaScript code, where a developer might need to locate an HTML element and update its contents directly.

C. Understanding isLoading

The component also declares:

private bool isLoading;

This Boolean field indicates whether a database operation is currently in progress. For example:

private async Task LoadBooksAsync()
{
    isLoading = true;
    errorMessage = null;

    try
    {
        await LoadBooksCoreAsync();
    }
    catch (Exception ex)
    {
        Logger.LogError(
            ex,
            "Failed to load books.");
        errorMessage = "Unable to load books.";
    }
    finally
    {
        isLoading = false;
    }
}

The method sets isLoading to true before starting the operation and resets it to false in the finally block. The finally block executes whether the operation succeeds or throws an exception.

The markup can use this state to display a loading message:

@if (isLoading)
{
    <p>Loading books...</p>
}

It can also disable a button while the operation is running:

<button disabled="@isLoading">
    Delete
</button>

This improves the user experience by providing feedback and helping prevent repeated clicks during an operation.

D. How These Three Pieces Work Together

The three fields and services have different responsibilities:

Name          Purpose

Logger        Records diagnostic information for
              developers and administrators.

errorMessage  Stores a message that can be displayed
              to the user when an operation fails.

isLoading     Indicates whether an operation is in progress.

For a typical database operation, the flow is:

1. Start the operation
   Set isLoading = true and clear the previous error.
2. Execute the database query
   Retrieve or modify data asynchronously.
   Success: Display the results and refresh the relevant data.
   Failure: Log the exception and set errorMessage.
3. Finish the operation
   Set isLoading = false in the finally block.

Together, these mechanisms make a Blazor page easier to use and easier to troubleshoot. They are not required for every simple demonstration, but they are valuable when building a more robust application.

Important Notes

• No Include() is needed. The query projects the publisher name directly into BookListItem. EF Core retrieves the selected values without materializing complete Book and Publisher entities.
• Filtering happens in SQL. Selecting a publisher adds a Where() condition before ToListAsync() executes the query.
• AsNoTracking() suits this read-only page. The component displays results rather than editing the retrieved entities.
• Each operation uses a short-lived context. The context is disposed after the query finishes.
• The UI handles common states. Readers can see loading feedback, an empty result, or a database error.

E. Test It in Visual Studio

• Build and run the project. From the Home page, click Manage Books link. The page should display:

• Filter by publisher: for example, select Pearson Education in the dropdown list.

• Continue the test. You can click Add Book, Edit, or Delete.

Conclusion

Entity Framework Core does more than map C# objects to database tables. It gives us tools to control how data is loaded, how queries are composed, and how much information is returned from SQL Server.

Include() remains valuable when related entities are needed. Explicit loading can help when related data is required only under certain conditions, while lazy loading deserves care because it can introduce hidden database operations.

LINQ projections and aggregate operations offer another important improvement: instead of retrieving entire entities for every task, we can ask the database for precisely the information the application needs. Short-lived contexts, asynchronous queries, and tools such as ToQueryString() help keep the data-access layer easier to reason about.

The central lesson is straightforward: good EF Core code is not about writing the fewest lines. It is about expressing the data requirement clearly and retrieving that data efficiently.

In the next article, we will build on these ideas by exploring LINQ filtering, sorting, and searching in greater depth, turning the library catalog into a more interactive application.

The journey will then look like this:

Article 1 — Connecting a Blazor Web App to SQL Server.
Article 2 — Configuring the model with Fluent API and migrations.
Article 3 — Implementing CRUD with EF Core.
Article 4 — Modeling relationships between publishers and books.
Article 5 — Loading related data and writing more advanced queries.
Article 6 — LINQ queries: filtering, sorting, and searching data

Your turn: In your own EF Core projects, do you prefer Include() or projection for read-only pages? Have you encountered unexpected database queries or performance issues? Share your experience in the comments, and if this article helped you understand EF Core data loading, consider sharing it with another .NET developer.

References

1. Microsoft. Efficient Querying. Microsoft Learn. https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying
2. Microsoft. Loading Related Data. Microsoft Learn. https://learn.microsoft.com/en-us/ef/core/querying/related-data/
3. Microsoft. Tracking vs. No-Tracking Queries. Microsoft Learn. https://learn.microsoft.com/en-us/ef/core/querying/tracking
4. Microsoft. Complex Query Operators. Microsoft Learn. https://learn.microsoft.com/en-us/ef/core/querying/complex-query-operators

EF Core & Blazor #5: Writing Smarter Queries & Loading Data Efficiently was originally published in Informatics on Medium, where people are continuing the conversation by highlighting and responding to this story.