Gestion de la Persistance des Données

Dans cette section, vous apprendrez comment Lino configure Entity Framework Core afin que la couche domaine reste totalement isolée et que les processus de migration de base de données soient prévisibles et contrôlés — que ce soit dans un service traditionnel (monolithique) ou dans un service modulaire.

Lors de la création d’un service via la commande lino new service, l’interface CLI demande deux décisions essentielles :

Architecture — service traditionnel ou modulaire.
Fournisseur de données — SqlServer ou PostgreSql (d’autres fournisseurs seront ajoutés dans de futures versions).

Dans les services traditionnels (monolithiques) ou modulaires (monolithiques modulaires), la base de données est unique par service. Cependant, dans les services modulaires, chaque module est mappé dans un schéma distinct au sein de la même base de données. Cela permet à chaque bounded context de conserver un espace de noms logique séparé, garantissant ainsi l’isolation fonctionnelle, le versionnage indépendant et des migrations plus organisées et sécurisées.

Configurations des types d’entité

Lino suit le principe Persistence‑Ignorant : les entités du domaine ne connaissent pas les détails de l’infrastructure. Pour cela, tout le mapping ORM est déplacé dans des classes qui implémentent IEntityTypeConfiguration<T>, situées dans Configurations/<EntityName>Configuration.cs.

Chaque entité possède un fichier de configuration dédié.
Les conventions globales (ex. : decimal(18,2), collation, DateTime en utc) peuvent être centralisées dans ModelConfiguration.
Les configurations sont appliquées dans la méthode OnModelCreating du DbContext via modelBuilder.ApplyConfigurationsFromAssembly(...).

DbContexts

Le DbContext représente l'unité de transaction de l’application. Lino génère automatiquement :

Service traditionnel — un unique AppDbContext contenant tous les DbSet<TEntity>.
Service modulaire — un <Module>DbContext par bounded context. Ainsi, chaque module compile plus rapidement, dispose de cycles de migration plus courts et réduit le risque de conflits de fusion.

Tous les DbContext sont enregistrés dans <Module>/Infrastructure.Persistence, exposés via IUnitOfWork et résolus par dependency injection.

Repositories

Les repositories concrets se trouvent dans <Module>/Infrastructure.Persistence.Repositories et implémentent les interfaces définies dans l’espace de noms <Module>/Domain.Repositories. Chaque repository :

Encapsule des requêtes complexes (LINQ, FromSql, projections DTO).
Expose uniquement les méthodes nécessaires au domaine (centré sur l’Aggregate Root).

Unité de Travail (Unit of Work)

L'Unité de Travail agit comme une frontière transactionnelle qui coordonne plusieurs dépôts, garantissant que toutes les opérations soient exécutées de manière atomique. Dans les scénarios simples, le DbContext lui-même est souvent suffisant. Cependant, Lino génère une implémentation dédiée (UnitOfWork) offrant un meilleur contrôle et une plus grande flexibilité.

Permet le contrôle manuel des transactions via BeginTransaction, Commit et Rollback, lorsque nécessaire.
Publie des événements de domaine pendant la transaction en cours, garantissant qu'ils se produisent dans le même cycle de commit.
Persiste des événements d'intégration dans la boîte d'envoi (outbox), suivant le Transaction Outbox Pattern, assurant une livraison fiable dans les architectures distribuées (le cas échéant).

Gestion des migrations

Lino simplifie et automatise entièrement le processus de migrations de base de données avec Entity Framework Core, éliminant les tâches répétitives et les risques courants d’incohérence. Pour créer une nouvelle migration, exécutez la commande suivante :

lino database migrations add

Lorsque vous exécutez la commande, un assistant interactif vous demandera les informations suivantes :

Service — Nom du projet où la migration sera appliquée.
Module — (uniquement pour les services modulaires) module auquel appartient la modification.
Nom de la migration — Indiquez une description du changement (ex. : AddCustomerIsActive). Lino prendra automatiquement en charge la version actuelle et l’ordre d’incrémentation lors de la génération du script .sql, suivant ce modèle : /Scripts/v1.2.3/001_AddCustomerIsActive.sql.

Note : En plus des fichiers .cs générés par Entity Framework, Lino crée automatiquement le script .sql correspondant avec les instructions DDL. Cela facilite l’exécution manuelle des modifications ou la révision par les équipes d’infrastructure et les DBA.