Blazor Helpers App: EF Core Tutorial


A tutorial on using Entity Framework Core based upon the two sample Blazor apps previously presnted here.

Entity Framework Core Tutorial

About

A number of blog posts in this series have discussed using Entity Framework Core for database access for a Blazor Helpers app. Helpers login and volunteer to perform various tasks as part of an athletics track meet, Whilst the app source isn’t public, some of the CRUD functionality has been discussed in those posts and refer to a couple of simplified Blazor apps as posted on GitHub. There is a Blazor Server (only) app as well a Blazor Wasm app, both of which use almost identical EF code. The immediately previous post specifically covered those two apps. This post is a tutorial exemplifying EF functionality and some related finer points using the apps.

Entity Framework

Ef Core enables code first code development for entity creation and instantiation as well as writing, reading, modifying and deletion of entities to and from a database. (You can though do data first with EF though.) Code first means you can define your entities with their properties directly as classes and generate the database and tables from these definitions. Entities can be interrelated in that one entity can be a property of another. EF hides the mechanisms for making his all work seamlessly. Also, if you change, add or delete a class definition, you do a migration and presto, the database structure gets updated as well as the data.

The EF focal point is the database context (DBContext). This is a gateway to the entities. Each entity is a table in the database. The entiies are a properties of the DBContext as a copy of all records in its database table as a collection for each entity. The collection can be queried. Individual entities (or a subcollection from the full list) can be modified, added to or deleted. EF tracks changes through the DBContext. Modifications to the entity collection such as additions or deletion as well as changes to individual entity property values are tracked by the DbContext and are only pushed through to the database when the DBContext is saved (DbContext.SaveChangesAsync()). The state of an entity can be queried through DBContext.Entry(<entity name>).State which after a modification will be Modified. It can be explicitly modified by assigning a value to the State:

  • Added

  • Deleted

  • Modified

  • Unchanged

  • Detached

If set to Unchanged, previous changes will be ignored upon DbContext.SaveChanges(). Detached means the DbContext won’t track changes to that entity. Ordinarily, the State does not need to be set explicitly as it is set by programmatically making entity changes.

Another complexity with entity cross referencing is that getting an entity list is incomplete without the actual entities that are properties of it. For example an activity has a helper and round. Therefore all helpers that are used by the list of activities need to be obtained. So when a list of activities is queried for .Include entries are appended for each referenced entity property so that all of the required data is present in-memory for the activity list. That way, for example, if activity are displayed, then Helpers’ names can be displayed without further queries. In the database, the entity property values are stored is Ids (Foreign Key). In more classic database coding, you queried for the activity/ies then used the foreign properties Ids to get the foreign entities as further queries using their Ids (or Primary keys). Using the .Include appendages, that is all handled implicitly. This also is of relevance with entity deletion. If an entity is a required property of another, then EF can be configured so that if an instance of the first entity is deleted then all instances of the second entity that have that specific entity instance as a property are deleted as well (Cascade delete). If not a required property of the referring entity, then EF can be configured to set the property to null instead for those entities that have it as a property.

This tutorial is an exercise in EF Core DBContext change tracking.

Tutorial

Getting Started

There are two apps. One is a Blazor server only and second is a Blazor Wasm app that implements the same EF Core backend. The server only app interacts with database with direct calls to a Service. The Wasm app client interacts indirectly with a similar Service in its server through a Controller Both have a similar set of Razor pages except that Wasm client apps uses http GET, POST, PUT and DELETE to action commands via the controller. The two apps are publicly available on GitHub and are also published as Azure Static Websites. If you clone the apps from GitHub, build and run them, they will run by default using IIS Express and SQL Server Express. The published versions using an Azure SQL Database. You may wish to use the Azure versions initially so as to get a quick start or clone the app solutions so as to drill in deeper with the code.

The app Repositories on GitHub are located at:

The apps as published to Azure Static Websites using an Azure SQL Database at:

Code the repositories, build and run the apps or just use the hosted apps. Note if using the hosted apps, they assume a single user at a time so there might be some simultaneous interaction if more than one user is on at a time. Both apps use a separate database and there are options to rebuild the database.

Getting Static Data

The Get Sample Data pages enable a set of data to be generated on the fly from a Json string, in the HelperService for the Server only app, and in a Controller for the Wasm app. It is regenerated whenever the page is reloaded and does not use the database. This page in the Server only app makes a direct call to the HelperService. The Wasm app has two such pages each coding the retrieval slightly differently. One page downloads the data as a Json string from the Controller using:

Http.GetAsync()

The string was generated from the Activities in the Controller (actually in effect the reverse if the initial generation of the Activity data) and deserialiizes in-page it into the Activity entities. With the other Wasm page, the Activities are retrieved directly from the Controller as entities using

Http.GetFromJsonAsync\<Activity[]\>()

The Helpers and Rounds both apps are extracted from the Activities for these pages.

  1. Run the apps and view these pages. Note that as they haven’t been assigned to the database, the entities do not have Ids yet (actually zero).

Create

Add

Delete

Update

<Coming>

 TopicSubtopic
  Next: > An Azure Static Web App with EF
   
 This Category Links 
Category:Blazor Index:Blazor
  Next: > Blazor Helpers App Members
<  Prev:   Blazor Helpers App