Dropping the Database and Running the Application

Use a browser to request http://localhost:5000/forms, which will produce a data table. Click one of the Edit buttons, and you will see a placeholder for the form and a summary showing the current property values of the selected Person object, as shown in Figure 36-1.

Creating Custom Form Components

The abstract TryParseValueFromString method has to be implemented so that the base class is able to map between string values used by HTML elements and the corresponding value for the C# model property. I don’t want to implement my custom select element to any specific C# data type, so I have used an @typeparam expression to define a generic type parameter. The Values property is used to receive a dictionary mapping string values that will be displayed to the user and TValue values that will be used as C# values. The method receives two out parameters that are used to set the parsed value and a parser validation error message that will be displayed to the user if there is a problem. Since I am working with generic types, the Parser property receives a function that is invoked to parse a string value into a TValue value.

I use the Entity Framework Core ToDictionaryAsync method to create collections of values and labels from the Department and Location data and use them to configure the CustomSelect components. Restart ASP.NET Core and request http://localhost:5000/forms/edit/2; you will see the select elements shown in Figure 36-3. When you pick a new value, the CustomSelect component will update the CurrentValueAsString property, which will result in a call to the TryParseValueFromString method, with the result used to update the Value binding.

Validating Form Data

The expression defines no parameters and selects the property from the object used for the Model attribute of the EditForm component and not the model type. For this example, this means the expression operates on the PersonData object and not the Person class.

To see the effect of the validation components, restart ASP.NET Core and request http://localhost:5000/forms/edit/2. Clear the Firstname field and move the focus by pressing the Tab key or clicking on another field. As the focus changes, validation is performed, and error messages will be displayed. The Editor component shows both summary and per-property messages, so you will see the same error message shown twice. Delete all but the first two characters from the Surname field, and a second validation message will be displayed when you change the focus, as shown in Figure 36-4. (There is validation support for the other properties, too, but the select element doesn’t allow the user to select an invalid valid. If you change a value, the select element will be decorated with a green border to indicate a valid selection, but you won’t be able to see an invalid response until I demonstrate how the form components can be used to create new data objects.)

Handling Form Events

Restart ASP.NET Core and request http://localhost:5000/forms/edit/2. Clear the Firstname field, and click the Submit button. In addition to the validation error, you will see a message indicating that the form was submitted with invalid data. Enter a name into the field and click Submit again, and the message will change, as shown in Figure 36-5.

Understanding the Entity Framework Core Context Scope Issue

To see the first issue, request http://localhost:5000/forms/edit/2, clear the Firstname field, and change the contents of the Surname field to La. Neither of these values passes validation, and you will see error messages as you move between the form elements. Click the Back button, and you will see that the data table reflects the changes you made, as shown in Figure 36-6, even though they were not valid.

In a conventional ASP.NET Core application, written using controllers or Razor Pages, clicking a button triggers a new HTTP request. Each request is handled in isolation, and each request receives its own Entity Framework Core context object, which is configured as a scoped service. The result is that the data created when handling one request affects other requests only once it has been written to the database.

In a Blazor application, the routing system responds to URL changes without sending new HTTP requests, which means that multiple components are displayed using only the persistent HTTP connection that Blazor maintains to the server. This results in a single dependency injection scope being shared by multiple components, as shown in Figure 36-7, and the changes made by one component will affect other components even if the changes are not written to the database.

Entity Framework Core is trying to be helpful, and this approach allows complex data operations to be performed over time before being stored (or discarded). Unfortunately, much like the helpful approach Entity Framework Core takes to dealing with related data, which I described in Chapter 35, it presents a pitfall for the unwary developer who expects components to handle data like the rest of ASP.NET Core.

Discarding Unsaved Data Changes

If sharing a context between components is appealing, which it will be for some applications, then you can embrace the approach and ensure that components discard any changes when they are destroyed, as shown in Listing 36-14.

@page "/forms/edit/{id:long}"

@layout EmptyLayout

@implements IDisposable

<!-- ...elements omitted for brevity... -->

@code {

    // ...statements omitted for brevity...

    public string FormSubmitMessage { get; set; } = "Form Data Not Submitted";

    public void HandleValidSubmit() => FormSubmitMessage = "Valid Data Submitted";

    public void HandleInvalidSubmit() =>

        FormSubmitMessage = "Invalid Data Submitted";

    public void Dispose() => Context.Entry(PersonData).State = EntityState.Detached;

}

Listing 36-14.

Discarding Unsaved Data Changes in the Editor.razor File in the Blazor/Forms Folder

As I noted in Chapter 35, components can implement the System.IDisposable interface, and the Dispose method will be invoked when the component is about to be destroyed, which happens when navigation to another component occurs. In Listing 36-14, the implementation of the Dispose method tells Entity Framework Core to disregard the PersonData object, which means it won’t be used to satisfy future requests. To see the effect, restart ASP.NET Core, request http://localhost:5000/forms/edit/2, clear the Firstname field, and click the Back button. The modified Person object is disregarded when Entity Framework Core provides the List component with its data, as shown in Figure 36-8.

Creating New Dependency Injection Scopes

You must create new dependency injection scopes if you want to preserve the model used by the rest of ASP.NET Core and have each component receive its own Entity Framework Core context object. This is done by using the @inherits expression to set the base class for the component to OwningComponentBase or OwningComponentBase<T>.

The OwningComponentCase class defines a ScopedServices property that is inherited by the component and that provides an IServiceProvider object that can be used to obtain services that are created in a scope that is specific to the component’s lifecycle and will not be shared with any other component, as shown in Listing 36-15.

@page "/forms/edit/{id:long}"

@layout EmptyLayout

@inherits OwningComponentBase

@using Microsoft.Extensions.DependencyInjection

<link href="/blazorValidation.css" rel="stylesheet" />

<h4 class="bg-primary text-center text-white p-2">Edit</h4>

<h6 class="bg-info text-center text-white p-2">@FormSubmitMessage</h6>

<!-- ...elements omitted for brevity... -->

@code {

    [Inject]

    public NavigationManager NavManager { get; set; }

    //[Inject]

    DataContext Context => ScopedServices.GetService<DataContext>();

    [Parameter]

    public long Id { get; set; }

    // ...statements omitted for brevity...

    //public void Dispose() =>

    //      Context.Entry(PersonData).State = EntityState.Detached;

}

Listing 36-15.

Using a New Scope in the Editor.razor File in the Blazor/Forms Folder

In the listing, I commented out the Inject attribute and set the value of the Context property by obtaining a DataContext service. The Microsoft.Extensions.DependencyInjection namespace contains extension methods that make it easier to obtain services from an IServiceProvider object, as described in Chapter 14.

Note

Changing the base class doesn’t affect services that are received using the Inject attribute, which will still be obtained within the request scope. Each service that you require in the dedicated component’s scope must be obtained through the ScopedServices property, and the Inject attribute should not be applied to that property.

The OwningComponentBase<T> class defines an additional convenience property that provides access to a scoped service of type T and that can be useful if a component requires only a single scoped service, as shown in Listing 36-16 (although further services can still be obtained through the ScopedServices property).

@page "/forms/edit/{id:long}"

@layout EmptyLayout

@inherits OwningComponentBase<DataContext>

<link href="/blazorValidation.css" rel="stylesheet" />

<h4 class="bg-primary text-center text-white p-2">Edit</h4>

<h6 class="bg-info text-center text-white p-2">@FormSubmitMessage</h6>

<!-- ...elements omitted for brevity... -->

@code {

    [Inject]

    public NavigationManager NavManager { get; set; }

    //[Inject]

    DataContext Context => Service;

    // ...statements omitted for brevity...

}

Listing 36-16.

Using the Typed Base Class in the Editor.razor File in the Blazor/Forms Folder

The scoped service is available through a property named Service. In this example, I specified DataContext as the type argument for the base class.

Regardless of which base class is used, the result is that the Editor component has its own dependency injection scope and its own DataContext object. The List component has not been modified, so it will receive the request-scoped DataContext object, as shown in Figure 36-9.

Restart ASP.NET Core, navigate to http://localhost:5000/forms/edit/2, clear the Firstname field, and click the Back button. The changes made by the Editor component are not saved to the database, and since the Editor component’s data context is separate from the one used by the List component, the edited data is discarded, producing the same response as shown in Figure 36-8.

Understanding the Repeated Query Issue

Blazor responds to changes in state as efficiently as possible but still has to render a component’s content to determine the changes that should be sent to the browser.

Each time the component is rendered, Entity Framework Core sends two identical requests to the database, even when the Increment button is clicked where no data operations are performed.

This issue can arise whenever Entity Framework Core is used and is exacerbated by Blazor. Although it is common practice to assign database queries to IEnumerable<T> properties, doing so masks an important aspect of Entity Framework Core, which is that its LINQ expressions are expressions of queries and not results, and each time the property is read, a new query is sent to the database. The value of the People property is read twice by the List component: once by the Count property to determine whether the data has loaded and once by the @foreach expression to generate the rows for the HTML table. When the user clicks the Increment button, Blazor renders the List component again to figure out what has changed, which causes the People property to be read twice more, producing two additional database queries.

Blazor and Entity Framework Core are both working the way they should. Blazor must rerender the component’s output to figure out what HTML changes need to be sent to the browser. It has no way of knowing what effect clicking the button has until after it has rendered the elements and evaluated all the Razor expressions. Entity Framework Core is executing its query each time the property is read, ensuring that the application always has fresh data.

This combination of features presents two issues. The first is that needless queries are sent to the database, which can increase the capacity required by an application (although not always because database servers are adept at handling queries).

The second issue is that changes to the database will be reflected in the content presented to the user after they make an unrelated interaction. If another user adds a Person object to the database, for example, it will appear in the table the next time the user clicks the Increment button. Users expect applications to reflect only their actions, and unexpected changes are confusing and distracting.

Managing Queries in a Component

The interaction between Blazor and Entity Framework Core won’t be a problem for all projects, but, if it is, then the best approach is to query the database once and requery only for operations where the user might expect an update to occur. Some applications may need to present the user with an explicit option to reload the data, especially for applications where updates are likely to occur that the user will want to see, as shown in Listing 36-18.

@page "/forms"

@layout EmptyLayout

<h5 class="bg-primary text-white text-center p-2">People</h5>

<table class="table table-sm table-striped table-bordered">

    <thead>

        <tr>

            <th>ID</th><th>Name</th><th>Dept</th><th>Location</th><th></th>

        </tr>

    </thead>

    <tbody>

        @if  (People.Count() == 0) {

            <tr><th colspan="5" class="p-4 text-center">Loading Data...</th></tr>

        } else {

            @foreach (Person p in People) {

                <tr>

                    <td>@p.PersonId</td>

                    <td>@p.Surname, @p.Firstname</td>

                    <td>@p.Department.Name</td>

                    <td>@p.Location.City</td>

                    <td></td>

                </tr>

            }

        }

    </tbody>

</table>

<button class="btn btn-danger" @onclick="UpdateData">Update</button>

<button class="btn btn-primary" @onclick="@(() => Counter++)">Increment</button>

<span class="h5">Counter: @Counter</span>

@code {

    [Inject]

    public DataContext Context { get; set; }

    public IEnumerable<Person> People { get; set; } = Enumerable.Empty<Person>();

    protected async override Task OnInitializedAsync() {

        await UpdateData();

    }

    private async Task UpdateData() =>

        People = await Context.People.Include(p => p.Department)

            .Include(p => p.Location).ToListAsync<Person>();

    public int Counter { get; set; } = 0;

}

Listing 36-18.

Controlling Queries in the List.razor File in the Blazor/Forms Folder

The UpdateData method performs the same query but applies the ToListAsync method, which forces evaluation of the Entity Framework Core query. The results are assigned to the People property and can be read repeatedly without triggering additional queries. To give the user control over the data, I added a button that invokes the UpdateData method when it is clicked. Restart ASP.NET Core, request http://localhost:5000/forms, and click the Increment button. Monitor the output from the ASP.NET Core server, and you will see that there is a query made only when the component is initialized. To explicitly trigger a query, click the Update button.

Some operations may require a new query, which is easy to perform. To demonstrate, Listing 36-19 adds a sort operation to the List component, which is implemented both with and without a new query.

@page "/forms"

@page "/forms/list"

@layout EmptyLayout

<h5 class="bg-primary text-white text-center p-2">People</h5>

<table class="table table-sm table-striped table-bordered">

    <thead>

        <tr>

            <th>ID</th><th>Name</th><th>Dept</th><th>Location</th><th></th>

        </tr>

    </thead>

    <tbody>

        @if  (People.Count() == 0) {

            <tr><th colspan="5" class="p-4 text-center">Loading Data...</th></tr>

        } else {

            @foreach (Person p in People) {

                <tr>

                    <td>@p.PersonId</td>

                    <td>@p.Surname, @p.Firstname</td>

                    <td>@p.Department.Name</td>

                    <td>@p.Location.City</td>

                    <td>

                        <NavLink class="btn btn-sm btn-warning"

                               href="@GetEditUrl(p.PersonId)">

                            Edit

                        </NavLink>

                    </td>

                </tr>

            }

        }

    </tbody>

</table>

<button class="btn btn-danger" @onclick="@(() => UpdateData())">Update</button>

<button class="btn btn-info" @onclick="SortWithQuery">Sort (With Query)</button>

<button class="btn btn-info" @onclick="SortWithoutQuery">Sort (No Query)</button>

<button class="btn btn-primary" @onclick="@(() => Counter++)">Increment</button>

<span class="h5">Counter: @Counter</span>

@code {

    [Inject]

    public DataContext Context { get; set; }

    public IEnumerable<Person> People { get; set; } = Enumerable.Empty<Person>();

    protected async override Task OnInitializedAsync() {

        await UpdateData();

    }

    private IQueryable<Person> Query => Context.People.Include(p => p.Department)

            .Include(p => p.Location);

    private async Task UpdateData(IQueryable<Person> query = null) =>

        People = await (query ?? Query).ToListAsync<Person>();

    public async Task SortWithQuery() {

        await UpdateData(Query.OrderBy(p => p.Surname));

    }

    public void SortWithoutQuery() {

        People = People.OrderBy(p => p.Firstname).ToList<Person>();

    }

    string GetEditUrl(long id) => $"/forms/edit/{id}";

    public int Counter { get; set; } = 0;

}

Listing 36-19.

Adding Operations to the List.razor File in the Blazor/Forms Folder

Entity Framework Core queries are expressed as IQueryable<T> objects, allowing the query to be composed with additional LINQ methods before it is dispatched to the database server. The new operations in the example both use the LINQ OrderBy method, but one applies this to the IQueryable<T>, which is then evaluated to send the query with the ToListAsync method. The other operation applies the OrderBy method to the existing result data, sorting it without sending a new query. To see both operations, restart ASP.NET Core, request http://localhost:5000/forms, and click the Sort buttons, as shown in Figure 36-10. When the Sort (With Query) button is clicked, you will see a log message indicating that a query has been sent to the database.

Avoiding the Overlapping Query Pitfall

You may encounter an exception telling you that “a second operation started on this context before a previous operation completed.” This happens when a child component uses the OnParametersSetAsync method to perform an asynchronous Entity Framework Core query and a change in the parent’s data triggers a second call to OnParametersSetAsync before the query is complete. The second method call starts a duplicate query that causes the exception. This problem can be resolved by performing the Entity Framework Core query synchronously. You can see an example in Listing 36-12, where I perform queries synchronously because the parent component will trigger an update when it receives its data.

Creating the List Component

The operations for creating, viewing, and editing objects navigate to other URLs, but the delete operations are performed by the List component, taking care to reload the data after the changes have been saved to reflect the change to the user.

Creating the Details Component

All the input elements displayed by this component are disabled, which means there is no need to handle events or process user input.

Creating the Editor Component

I added support for a new URL and used Bootstrap CSS themes to differentiate between creating a new object and editing an existing one. I removed the validation summary so that only property-level validation messages are displayed and added support for storing the data through Entity Framework Core. Unlike form applications created using controllers or Razor Pages, I don’t have to deal with model binding because Blazor lets me work directly with the object that Entity Framework Core produces from the initial database query. Restart ASP.NET Core and request http://localhost:5000/forms. You will see the list of Person objects shown in Figure 36-11, and clicking the Create, Details, Edit, and Delete buttons will allow you to work with the data in the database.

Creating a Custom Validation Constraint

This component enforces a restriction on the state in which departments can be defined so that, for example, locations in California are the valid options only when the Development department has been chosen, and any other locations will produce a validation error.

The component has its own scoped DataContext object, which it receives by using OwningComponentBase<T> as its base class. The parent component provides values for the DepartmentId and State properties, which are used to enforce the validation rule. The cascading EditContext property is received from the EditForm component and provides access to the features described in Table 36-8.

The arguments to the Add method are a FieldIdentifier that identifies the field the error relates to and the validation message. If there are no validation errors, then the message store’s Clear method is called, which will ensure that any stale messages that have been previously generated by the component are no longer displayed.

The DepartmentId and State attributes specify the restriction that only locations in California can be selected for the Development department. Restart ASP.NET Core and request http://localhost:5000/forms/edit/2. Choose Development for the Department field, and you will see a validation error because the location for this Person is New York. This error will remain visible until you select a location in California or change the department, as shown in Figure 36-12.

Creating a Valid-Only Submit Button Component

This component responds to the OnValidationStateChanged method, which is triggered when the validation state of the form changes. There is no EditContext property that details the validation state, so the best way to see if there are any validation issues is to see whether there are any validation messages. If there are, there are validation issues. If there are no validation messages, the form is valid. To ensure the button state is displayed correctly, the Validation method is called so that a validation check is performed as soon as the component is initialized.

Restart ASP.NET Core and request http://localhost:5000/forms/create; you will see the validation messages displayed for each form element, with the Save button disabled. The button will be enabled once each validation issue has been resolved, as shown in Figure 36-13.