Blazor App: Lazy loading of properties a fix


Using an AI Coding tool to modify a Blazor app to replace enum lists with SQL tables. The process involved creating new tables, populating them from the enums, and modifying the code to use the new tables. Challenges included handling null values and ensuring proper loading of properties. The solution involved adding name properties for lazy loading and updating the UI code accordingly. This approach allows for easier maintenance and updates without needing to rebuild or redeploy the app.

Preamble

“In the midst of all the joy wrt token costs with AI LLMs” I have been using AI for code development. In particular I have been using the WindSurf app with a Pro subscription. Last month with the changes made to Token consumption, I found that I needed to be a bit more prudent with the choice of LLM and the structure of queries. WindSurf now has daily and weekly quotas. If you choose to use a top level LLM then you blow you budget very quickly. I am though interested in discussions about the advantages and disadvantages of using LLMs with a larger quota cost in the coding context. Have there been any quantitative studies comparing efficiencies of low token cost LLMs with higher token cost LLMs? The problem though with such a study probably is that once a sequence of queries have been used to develop, say, an app, with one LLM, that information would probably filter through to a second sequence of the queries with an alternative LLM. Had to make comparisons in a vacuum. Also, in making comparisons, would you focus upon how quickly the task was completed (read number of tokens*token cost), how much it could remember, how often it went around in circles or hallucinated, etc? Or how good the outcome was.

Nb: Just discovered this Leaderboard: Best LLM Leaderboard 2026 | AI Model Rankings

A Recent Task

I have in the last day or so decided to modify a Blazor Service app that has been in operation for several years with many library updates, code improvements and functional additions. The app is hosted online on Azure and prvides a mechanism for Helpers to volunteer on behalf a sporting club for assigned tasks that the club has been by the sporting association for association meets. Each meet has a Location and Competition type.

The task here was to replace the enum lists for Location and Competition types with tables in the app’s SQL database. These entities don’t often require additional entries so to add additional locations or competitions, the approach has been to add them at the end of the list in the code, rebuild and then redeploy to Azure. It was decided to make the app a bit more “bullet proof” by doing this. The outcome at this stage is 2 new tables in the database with matching names to the enum names, along with a database Id. The code transposed the enums to populate the tables. Code was then modified to use the new entity’s Ids and names. After testing, the references to the enums were removed and the app was further tested. At this point, adding a new location or competition is done directly in the database management app (SSMS). A later refinement will be to facilitate this in the Blazor app by an Admin.

Experience in doing so

Query: Have 2 enum lists that what to migrate to sql tables It listed all enum types in the application Response: Specify which 2 enum lists you want to migrate to SQL tables Query: Data/Locations in Activitys.cs and Data/CompetitionType in AVSL.cs Do one at a time starting with Locations please. First Outcome (eventually): The Locations table was created in the database and populated from the enums via Entity Framework. Code was modified to load the table and use this in place of the Location enums. This all worked well when tested but later it was found that the Id for a location referred to a location incremented by one. This was manually fixed in the database management app. Luckily for later, the app repository was updated at this time.

Second enum Replacement

Query: Re: Data/CompetitionType enum in AVSL.cs Lets similarly make that a sql table as well This bumbled along going in circles and not having infinite memory was apt to repeat itself. Eventually I pulled the plug, cancelled and reverted to the last repository commit. This time I used WindSurf in a more managed way, not just saying, “Go for it!”. The proposed new approach was to:

  1. Generate the new table dbCompetition and add the enum Competition values as entries, in isolation.
  2. Leave the enum Competition property in Program class but add a new property dbCompetition property that uses values in dbCompetition table.
  3. Iterate through the Programs list and for each Competition property value, look up its corresponding value in dbCompetitions and insert the Id there into the Program instance dbCompetitionId property or insert the found dbCompetition directly in the Program instance dbCpmpetition property directly using Entity Framework. The actual steps taken for the second property mirrored what was had been added for the first property but were done manually.
var programs = await _context.AVSLPrograms.ToListAsync();

Steps 1 and 2 worked OK but step 3 required a bit “brute force”. It was found that when Programs list was loaded, and filtered, whilst the new property Ids where retrieved, the actual property for each instance was null. The new properties loading wasn’t working properly. A workaround was, whenever the Program list was retrieved, the list was iterated through and the property values were inserted by looking up their values in the new tables. This was rather cumbersome.
Later some lazy-loading code was added :

var programs = await _context.AVSLPrograms.Include(p => p.Location).Include(c => c.dbCompetition).ToListAsync();

When loaded as such, upon inspection, the Location and dbCompetition properties were still null. The solution was to add a name property for each to the Program class for each of the two properties that uses the values. This forces the property vale lookups. It also handles returning “Unknown” when the Id for a property is null. In the Program class:

[NotMapped]
[JsonIgnore]
public string dbCompetitionName
{
    get
    {
        return dbCompetition?.Name ?? "Unknown";
    }
}

Then use the dbCompetitionName in the UI code. Eg: Originally using the enum property:

<GridColumn Field="@(nameof(AVSLProgram.Competition))" Title="Competition" Width="150px" />

Was replaced with using the tabled property:

<GridColumn Field="@(nameof(AVSLProgram.dbCompetition))" Title="Competition" Width="150px" />

And then then the generated property:

<GridColumn Field="@(nameof(AVSLProgram.dbCompetitionName))" Title="Competition" Width="150px" />

Conclusion

This coding can/should be improved by adding the virtual moniker in the Program class for these properties … later, but hey this is a significant improvement rom a coding perspective. When a new location or competition is needed, it can be directly added to their tables in the database without any need to rebuild or redeploy the app.

 TopicSubtopic
<  Prev:   Azure Front Door Update
   
 This Category Links 
Category:Artificial Intelligence Index:Artificial Intelligence
<  Prev:   Checkers-Draughts Game