Agenda accessible Web et MAUI

Prototype

Agenda

Un calendrier, deux environnements : une interface partagée entre le Web et une application MAUI.

Objectif
Partager l’interface et la logique métier sans les dupliquer entre les hôtes.
Points clés
Blazor, MAUI, API, EF Core, architecture multi-hôte, tests et CI.
Web Mobile Backend Architecture Accessibilité
Calendrier mensuel Agenda en thème sombre pour août 2026 avec un événement sélectionné et son panneau de détail.
Vue mensuelle et panneau d’événement en thème sombre.

Problème

Le problème à résoudre

Concevoir un agenda accessible dont les mêmes composants Razor et cas d’usage peuvent fonctionner dans plusieurs hôtes sans confondre interface, règles métier et persistance locale.

Architecture

Les pièces du système

  • Agenda.Domain porte les événements, catégories et invariants métier.
  • Agenda.Contracts définit les DTO et contrats d’entrée/sortie utilisés par les hôtes.
  • Agenda.Application orchestre les cas d’usage et dépend d’une abstraction de repository.
  • Agenda.Infrastructure fournit EF Core, SQLite, migrations et initialisation de la base.
  • Agenda.Ui contient les composants Razor réutilisés par Agenda.Web et Agenda.Maui.
  • Agenda.Api expose les cas d’usage via des Minimal APIs, tandis que l’hôte MAUI conserve sa propre base locale privée.

Décisions

Décisions techniques

  • Partager l’interface plutôt que la dupliquer. Les composants Razor restent dans Agenda.Ui afin que Web et MAUI utilisent la même interface métier au lieu de maintenir deux implémentations séparées.
  • Garder les cas d’usage hors des hôtes. Web, API et MAUI s’appuient sur Agenda.Application afin que les règles d’orchestration ne dépendent pas du mode d’hébergement.
  • Assumer une persistance locale par hôte. L’application MAUI utilise une base dans son répertoire privé ; aucune synchronisation implicite avec l’API n’est inventée tant que cette fonction n’est pas implémentée.
  • Versionner le schéma SQLite. EF Core et les migrations maintiennent l’évolution du stockage local au lieu de recréer systématiquement la base.

Schéma

Vue d’ensemble de l’architecture

Le schéma complète l’étude de cas avec les composants et frontières réellement présents dans le projet.

Schéma multi-hôte d’Agenda reliant Web Blazor, MAUI Blazor Hybrid et API aux couches UI, Application, Domain et Infrastructure.
Architecture multi-hôte avec interface Razor partagée et persistance SQLite locale.

Implémentation

Points techniques principaux

  • Calendrier mensuel avec navigation, sélection de journée et aperçu des événements.
  • Création, modification et suppression d’événements horaires ou sur une journée entière.
  • Interface Razor partagée entre Blazor Interactive Server et MAUI Blazor Hybrid.
  • API REST dédiée avec Minimal APIs et document OpenAPI en développement.
  • Persistance locale EF Core/SQLite avec migrations et données d’exemple.
  • Validation métier des périodes et longueurs de texte, interface responsive et navigation clavier.
  • Tests séparés par couche, vérification du formatage, audit NuGet et CI GitHub Actions.

Difficultés

Difficultés résolues

  • Partager une UI entre deux modèles d’hébergement. Les composants Razor doivent fonctionner à la fois dans Blazor Interactive Server et dans le WebView MAUI sans déplacer les cas d’usage dans les vues.
  • Conserver des règles temporelles cohérentes. Le domaine valide notamment que la fin d’un événement est postérieure au début et normalise les dates avant persistance.
  • Adapter le stockage à chaque hôte. Web/API utilisent une base de développement au niveau du dépôt alors que MAUI cible FileSystem.AppDataDirectory sans changer le contrat applicatif.

Qualité

Tests et garde-fous

  • Nullable activé, avertissements traités comme des erreurs et builds déterministes.
  • Tests séparés pour le domaine, l’application, l’infrastructure et l’interface.
  • Vérification du formatage et audit des vulnérabilités NuGet transitives.

Livraison

Livraison et CI/CD

  • make verify exécute la chaîne de validation locale.
  • GitHub Actions installe .NET 10 puis exécute make verify sur develop, branches de travail et pull requests.
  • Des commandes séparées lancent l’hôte Web, l’API et les workflows MAUI/Android.

Résultats

Résultats observables

  • Une application Web opérationnelle pour le CRUD d’événements et le calendrier mensuel.
  • Une API REST/OpenAPI utilisant les mêmes cas d’usage que l’interface.
  • Un hôte MAUI Blazor Hybrid intégré avec persistance SQLite locale privée.

Compromis

Compromis techniques

  • Le partage Razor réduit la duplication mais impose de conserver les composants UI compatibles avec les contraintes du Web et de MAUI.
  • La base locale MAUI rend l’application exploitable hors ligne, mais les données ne sont pas synchronisées avec l’API dans cette version.
  • La solution Web/API reste indépendante des workloads MAUI pour garder une CI légère, au prix de deux solutions/outils de build à maintenir.

Limites

Les limites actuelles

  • La synchronisation MAUI ↔ API n’est pas implémentée.
  • Les notifications natives ne sont pas implémentées.
  • L’authentification et les comptes multiples ne font pas partie de ce prototype.

Suite

Prochaines étapes

  • Définir un vrai protocole de synchronisation et de résolution de conflits avant de relier la base MAUI à l’API.
  • Ajouter les notifications natives lorsque leur cycle de vie peut être testé sur les plateformes ciblées.
  • Introduire authentification et multi-utilisateur uniquement si le projet évolue au-delà du prototype local.

Captures

Quelques écrans pour parcourir le projet.

Synthèse

Compétences et techniques mobilisées

  • Réutilisation d’une même UI et des mêmes cas d’usage dans plusieurs modèles d’hébergement .NET.
  • Domain, Contracts, Application et Infrastructure sont séparés et réutilisés par les hôtes Web, API et MAUI.
  • Navigation clavier, persistance SQLite locale, tests par couche, formatage et audit NuGet sont inclus dans le périmètre.

Aperçu agrandi