Dot Net What Not Posts

The problem Whilst I have mostly got the hang of async/await, I still find unexplored corners of the subject that catch me out. I came across one the other day that was (in retrospect) so obvious that I’m surprised it never caught me out until then. This blog post is an attempt to explain the problem and solution, so that when I want to remember the hows and whys in a few months, I will have something to read! As my regular reader will know, I am not under any illusions that anyone else reads my blog, nor that anyone else find it useful. I use it as a place to make notes of things that I’m likely to want to find again. If it helps anyone else, well that’s just a bonus! The actual background to the use case is irrelevant, so I’ll illustrate with a trivial example. Suppose…

The Blazor web app template introduced in .NET8 has some excellent features, but also has some subtle gotchas that can cause performance issues if you don’t handle them.

This post explains a utility class I wrote that will keep data access to a minimum when dealing with both server and client rendering, as well as caching data between navigations around the client code.

Last month, I explained how we had achieved a significant performance improvement by using Dapper to pull the data from the database, rather than using EF Core.

Whilst showing this to a colleague, he reminded me that EF Core has a FromSqlRaw method that does pretty much the same thing. Assuming that EF Core would be slower than Dapper, I didn’t give it much thought at the time. However, being a compulsive tinkerer, I decided to take a closer look.

This post explains my findings, and what I did with them

Due to some performance issues, I decided to try using Dapper with the Telerik grid for Blazor. This post documents the (excellent) results, and shows a useful extension method that makes this very simple.