Development With A Dot

Those that follow this blog probably know about my series of posts on soft-deletes with EF Core, which you can find here:

This is post 4 on a series of posts on soft deletes with EF Core. On none of my posts on this series did I mention that these solutions do not work with bulk deletes, introduced in EF Core 7, but they really don't. That is because they rely on the change tracking mechanism and the bulk delete and bulk update functionality does not use it. But as with most of EF Core, there is certainly a way around it, and in this post I will present one, using IQueryExpressionInterceptor, one of the new interceptors introduced in EF Core 7. There is also an open ticket for adding an interceptor mechanism for bulk updates, which will probably also include bulk deletes.

One feature that has been conspicuously missing from EF Core is read-only entities, meaning, the possibility to mark an entity type as read-only, in which case, no changes to its instances (inserts, updates, deletes) will be allowed; data needs to be added to the database by other means. There is currently an open ticket to track this functionality, which has been open for quite some time. While it is currently not possible to achieve exactly this functionality, there are some possible workarounds that require very little coding.

Update: SoftDeleteConvention is now generic.

Second post on a new series on software architecture. First one here, on high-level system communication. This time I’m going to talk a bit about data storage and how to access the data.

We all know O/RMs aren't the fastest tools when it comes to loading data, and Entity Framework Core is surely no exception. After all, they need to do a lot of operations, such as translating LINQ queries to SQL, instantiating the right entities, hydrating them (setting their properties from the database-retrieved values), taking a snapshot for the change-tracking functionality, etc, etc. But there, however, are a few things that we can do to help speed things a bit! Here are a few tips for you to make the best usage of Entity Framework Core.

When you have an existing deployed REST API that you want to change, you generally need to be very careful. Why would you want to change it? There can be a number of reasons:

Last year I blogged about the then current status of EF Core, its limitations, especially when compared with other O/RMs, such as NHibernate, one of my favourites. With the recent release of EF Core 8, it’s time to revisit that post.