A day in the life of...

The application I am currently working on loads text files, transforms them, and then saves them as relational data. I use Entity Framework Core with SQL Server for my persistence. Unfortunately, when inserting so much data I keep experiencing exceptions because SQL Server is throwing deadlock exceptions and preventing my data from being saved. The insert involves data for 4 related tables, every access to the DB is an insert, which is why I was so surprised to see SQL Server couldn't cope with it - especially as Firebird SQL didn't struggle (nor did PostgreSQL).  It seems that adding OPTION (LOOP JOIN) to the end of SQL Statements prevents this problem, so I wrote an extension to ensure it is appended to Entity Framework Core generated SQL. It is used like so: protected override void OnConfiguring(DbContextOptionsBuilder options) { base.OnConfiguring(options); options.UseLoopJoinQueries(); } and the extension code you need is: public static class UseLoopJoinQueriesExte...

Note: This agorithm was co-authored by Phillipa Berresford. I wanted my domain classes to be able to reference each other by Id without having to add association properties - as I felt having all of this navigation in the model made it messy. I'd much rather have association properties within my aggregates (PurchaseOrder to PurchaseOrderLines) but not elsewhere. This was okay when I needed to add a reference to an object that already existed in the DB, but when I was adding a reference to a new object I needed to know the object's Id before Entity Framework Core saved it to the DB. As my tables were using DB assigned incrementing INT columns this was not possible, so it become obvious I was going to have to switch to GUID Ids. The problem with using GUIDs as clustered primary keys is that GUIDs are designed to be random. Whereas an auto-incrementing INT key will always result in new rows being appended to the end of a table, GUID keys would result in new rows being inserted...

If you want your Blazor component to have its own dependency injection scope, so you can inject new instances of services and have those services disposed of when the component is disposed, then do the following: First, copy and paste the code below into your application.  Then descend your component from ScopedComponentBase . Finally, decorate your dependency properties with [InjectScoped] rather than [Inject] or @inject . For example @inherits ScopedComponentBase @code { [InjectScoped] private WeatherService MyWeatherService { get; set; } } Here is the code you need using Microsoft.AspNetCore.Components; using System; using System.Collections.Concurrent; using System.Collections.Generic; using System.Linq; using System.Reflection; namespace BlazorApp130.Shared { public abstract class ScopedComponentBase : OwningComponentBase<IServiceProvider> { protected override void OnInitialized() { base.OnInitialized(); DependencyInjector.InjectDependenc...

If you need something like JavaScript's setTimeout in Blazor, you can achieve the same thing with a System.Threading.Timer: The time sponsored by Accurist is @Time private string Time { get; set; } protected override void OnInit() {  var timer = new System.Threading.Timer((_) => {   Time = DateTime.UtcNow.ToString();   InvokeAsync(StateHasChanged);  }, null, 0, 1000);  base.OnInit(); }

I was really pleased to see my Blazor library "Fluxor" mentioned in this Visual Studio Magazine article!!!

I saw a post on Twitter from a guy named David McCarter  promoting his new book.  Rock Your Code: Defensive Programming for Microsoft .NET . I thought the title looked interesting so I bought it. This book (if approximately 50 pages of A5 can count as a book) was packed with bad advice. It is going to be more effort to explain why than the book deserves, but I will do it. TL;DR Source code doesn't compile. When it does, it doesn't do what the author says it does. The author promotes practices long established as poor. Chapter 1: OOP This chapter explains the three pillars of OOP are Encapsulation, Inheritance, and Polymorphism. The author has a tiny 1 or 2 sentence explanation of each. He then goes on to show an example of some poor source code "from a real in production project" (I hope he has permission from the copyright holder). The source code is a single class with lots of public attributes. That's the end of the chapter. Honestly, th...

If you have an Observable<x> in your component you might find yourself doing something like this {{ ( source$ | async)?.property1 }} {{ ( source$ | async)?.property2 }} This will subscribe to the source$ observable more than once. A commonly used technique to avoid this is to assign the result of the async into a view variable, like so: <ng-container ngif="source$ | async as source">   {{ source?.property1 }}   {{ source?.property2 }} </ng-container> But if you have other UI elements within that ng-container that you want to be displayed whether or not source$ has emitted a value then you might not like the fact that a portion of your UI is excluded until the observable emits a value or when the observable emits a falsey value. If that is the cast, you can try this little trick. <ng-container ngif="(source$ | async) || {} as source">   {{ source.property1 }}   {{ source.property2 }} </ng-container> We utilise *ngIf ...