Multi-tenancy

Ce volet explique comment déplacer un tenant d’une base partagée vers une base dédiée sans arrêter l’application ni perturber les autres tenants. Le catalogue pilote le basculement, tandis que le même modèle EF Core et son filtre restent en place dans les deux modes.

La migration s’appuie sur une copie initiale, un passage temporaire en lecture seule, une copie delta et une vérification avant le cutover. Le runbook attend l’expiration du cache avant de rouvrir les écritures : les instances qui conservent encore l’ancienne connexion ne peuvent ainsi pas écrire dans la base partagée après le basculement.

Avec une base par tenant, EF Core n’a plus besoin de filtre global, de colonne TenantId ni de clé de cache de modèle spécifique : le choix du tenant passe par une chaîne de connexion résolue depuis une base catalogue.

Cette isolation simplifie le modèle, mais déplace la complexité vers l’exploitation : chaque migration doit s’appliquer à toutes les bases. L’article détaille aussi le rôle de IDesignTimeDbContextFactory pour permettre à dotnet ef de créer le contexte sans requête ni tenant actif.

Cette partie 2/4 montre comment isoler les données de chaque tenant dans son propre schéma SQL Server, sans filtre global ni colonne TenantId obligatoire. Le modèle EF Core retrouve ainsi une clé primaire simple, tandis que la frontière d’isolation est portée par la structure de la base.

Le changement central tient au cache du modèle : OnModelCreating ne s’exécute qu’une fois par modèle. Il faut intégrer le schéma à la clé via IModelCacheKeyFactory, faute de quoi EF Core peut réutiliser celui du premier tenant. L’article détaille aussi le provisionnement et les migrations par schéma, ainsi que la validation stricte des noms de schéma interpolés dans le SQL.