Development with a Dot

Introduction One more for the EF Core pitfalls series . EF Core offers essentially two ways to get a record with a known primary key: The native  Find / FindAsync methods from DbContext  or DbSet<T> A regular Where clause followed by one of First / FirstOrDefault  or Single / SingleOrDefault , both from standard  LINQ extensions , or FirstAsync / FirstOrDefaultAsync , SingleAsync / SingleOrDefaultAsync , the asynchronous alternatives from the EF Core LINQ extensions There are a few differences between these approaches, and also a couple limitations, which I'll cover here. I will use as example a blogging domain model, where a Blog has many Posts , each Post references its Blog , and a Post has many Comments . Like in other tips, this may or may not be a pitfall, but there is a possibility that we are not counting on this. Using Find/FindAsync Methods Find / FindAsync  methods are great, because they allow us to retrieve a single entity wi...

These are the posts in the series: Entity Framework Core Pitfalls: Calling DB Functions in LINQ Queries as Extension Methods Entity Framework Core Pitfalls: Asynchronous vs Synchronous Calls and Interceptors Entity Framework Core Pitfalls: Getting a Single Record by Key

Introduction We all know  EF Core Migrations . They have been around for quite some time, some people like them, others prefer alternatives (hello, Flyway , DbUp , FluentMigrator !). I'm not going to discuss that, but, instead, how to seed data to a database, either using EF Core migrations or not. This is, of course, for inserting initial/reference data that must always be present, for Microsoft's opinion on this, please see this page . This post assumes that you know about migrations - how to create and apply them, at least, and that you have all it takes for it, including  EF Core Tools  and the  Microsoft.EntityFrameworkCore.Design  NuGet package. Migrations and the creation methods ( EnsureCreated , EnsureCreatedAsync ) are mutually exclusive , so you need to pick one, depending on your strategy. For actually adding data, we have essentially four options: Explicit insertions Data-only migrations Entity configuration Context configuration (explicit seeding)...

Introduction How many times have you tried to save changes to your context only to get an exception about validation problems, like a required property being null ? I certainly have, and because of this, I came up with a solution to figure out what is happening. I will also provide some possible solutions for the problem of fully validating an entity using the Data Annotations API  (a post on general validation with Data Annotations here ). State Validation All the entities that are currently tracked by a DbContext have some state known to the context. This state includes: The entity's state ( State ) in regards to persistence ( Modified , Added , Deleted , Unchanged ) Each property's values ( Property ), both current ( Current ) and original ( Original ) The entity itself ( Entity ) Any navigation properties ( References , Navigations ) So, we can iterate through each tracked entry by means of the Entries , Entries<T> , or Entry methods: var entity = ...; var ent...

Introduction In EF Core (as in most O/RMs) we can map and store multiple things: Objects that hold a single value, like int , string , bool , float , Guid , DateTime , TimeSpan , Uri , etc. These are (somewhat wrongly) called primitive types  and are always included inside some container, like the following Objects that hold multiple single values and which have an identity, for example, Customer , Product , Order . These are called entity types  and they must have an identity that makes them unique amongst all the other objects of the same type Objects that are structured to hold multiple values, but have no identity, such as Address , Coordinate . These are called value types  and are merely a collection of (possibly related) properties We can also have collections of the previous things There's more to it, of course, for example, it is even possible to represent  inheritance of entities , of which I talked about before , In this post I am going to cover so...

Introduction Multitenancy is a hot topic, which I covered a few times on my old blog. I won't dwell on its concepts, but, instead, I will present ways to apply multitenancy to EF Core. When it comes to data, multitenancy means that we should only retrieve data for the current tenant. I will present three ways to obtain the tenant id from inside of a  DbContext , which can then be used to set up query filters, connection strings, or mapping configuration. Multitenancy in Databases So, as I blogged before, there are essentially three strategies for applying multitenancy to databases: Using a tenant column on tenant-aware tables and filter by it Using a different schema, meaning, tenant-aware tables will be duplicated in different schemas and for each request, one schema will be used Using different databases, one for each tenant, and, for each request, pick the right connection string There are obviously pros and cons to each approach, but I won't go through them now. Instead,...

Note: this is an update to an old post on my old blog . Introduction EF Core 7  finally delivered a long-sought desire: all of the three  table inheritance patterns  are now implemented. These are: Table Per Hierarchy  ( TPH ) /  Single Table Inheritance : all columns for the properties of base and all derived classes are stored on the same, single, table, one for each base class (implemented in EF Core 1); Table Per Type  ( TPT ) /  Class Table Inheritance : columns for the properties of each class (abstract or otherwise) are stored on an individual table, and linked to tables that contain the columns for the properties for each base class through foreign keys (EF Core 5); Table Per Concrete Type  ( TPC ) /  Concrete Type Inheritance : a table exists for each concrete class which contains columns for each property of that class (EF Core 7). All of these patterns were discussed at length on  Martin Fowler ’s book,  Patterns of Ente...