Aller au contenu principal

Architecture .NET Framework 4.8

Architecture technique de la plateforme APS basée sur .NET Framework 4.8 et les patterns modernes d'injection de dépendances.

Vue d'ensemble​

APS (Avanteam Process Studio) est une plateforme applicative construite sur .NET Framework 4.8 qui tire parti des technologies Microsoft modernes tout en maintenant une compatibilité avec l'écosystème .NET complet. L'architecture repose sur des principes solides de séparation des responsabilités, d'injection de dépendances et de modularité.

Technologies principales​

  • .NET Framework 4.8 : Framework principal pour la majorité des composants
  • ASP.NET : Pour l'application web historique (Web.Model)
  • Microsoft.Extensions.DependencyInjection : Container IoC standard Microsoft
  • Entity Framework Core : ORM pour l'accès aux données
  • OWIN : Middleware pour SignalR et autres composants

Injection de dépendances​

L'architecture APS utilise le pattern d'injection de dépendances (DI) comme mécanisme principal pour gérer les dépendances entre composants.

Container IoC​

Le container IoC utilisé est Microsoft.Extensions.DependencyInjection, le container standard de Microsoft, offrant :

  • Enregistrement de services avec différentes durées de vie (Singleton, Scoped, Transient)
  • Support de l'injection par constructeur
  • Résolution automatique des dépendances
  • Intégration native avec ASP.NET Core et compatible avec ASP.NET Framework via des adaptateurs

ApsAppBuilder​

La configuration du container DI s'effectue via la classe ApsAppBuilder, qui fournit une API fluide pour enregistrer les services :

var apsAppBuilder = new ApsAppBuilder<ApplicationDependencyInjection>(
    webAppbuilder.Configuration,
    webAppbuilder.Services,
    webAppbuilder.Build,
    serviceProviderAccessor);

apsAppBuilder
    .AddKernel()
    .AddDirectoryWeb()
    .AddDirectoryApi()
    .AddApplicationApi()
    .AddStartupExtensions("Web.Model");

Chaque module de l'application expose une méthode d'extension Add{Module} qui encapsule l'enregistrement de ses services.

Modèle Startup​

Chaque module de l'application définit une classe Startup (ou {Module}Startup) qui centralise la configuration des services :

Exemple : DirectoryStartup

public static class DirectoryStartup
{
    public static IApsAppBuilder AddDirectory(
        this IApsAppBuilder apsAppBuilder)
    {
        AddServices(apsAppBuilder.Services);
        return apsAppBuilder.AddStartupExtensions("Directory");
    }

    private static void AddServices(IServiceCollection services)
    {
        services.AddDbContext<DirectoryContext>();
        services.TryAddScoped<IResourceManager, ResourceManager>();
        services.TryAddScoped<IUserManager, UserManager>();
        // ... autres services
    }
}

Ce pattern permet :

  • Une configuration modulaire et découplée
  • Un enregistrement déclaratif des services
  • Une extension facile par de nouveaux modules

Durées de vie des services​

Les services sont enregistrés avec des durées de vie appropriées :

  • Singleton : Services partagés durant toute la vie de l'application (configuration, factories)
  • Scoped : Services liés à une requête HTTP ou un scope applicatif (contextes EF, managers)
  • Transient : Nouvelle instance à chaque injection (services légers, sans état)
services.TryAddSingleton<IConfiguration>();
services.TryAddScoped<IDocumentManager, DocumentManager>();
services.TryAddTransient<IPasswordPolicyLocalizer, PasswordPolicyLocalizer>();

Couches architecturales​

L'application est structurée en couches logiques distinctes, chacune ayant une responsabilité claire.

Couche Kernel​

Le Kernel constitue le socle de l'application et fournit les services transversaux :

  • Configuration : Lecture et gestion de la configuration (fichiers .ini, appsettings.json)
  • Data Source : Abstraction de l'accès aux données
  • Dependency Injection : Infrastructure DI et service locator
  • Logging : Services de journalisation (NLog)
  • Mail : Envoi d'emails
  • Parameters : Gestion des paramètres applicatifs

Le Kernel ne dépend d'aucune autre couche et peut être utilisé de manière autonome.

Couche Directory​

Le module Directory gère tout ce qui concerne l'annuaire et l'authentification :

  • Identity : Modèle utilisateurs, ressources, organisations
  • Authentication : Authentification (Forms, Windows, SAML, OAuth)
  • Authorization : Gestion des autorisations et politiques
  • Synchronization : Synchronisation avec Active Directory / LDAP

Composants principaux :

  • DirectoryContext : Contexte utilisateur (nom, rôles, groupes)
  • IUserManager : Gestion des utilisateurs
  • IResourceManager : Gestion des ressources de l'annuaire
  • IDelegationManager : Gestion des délégations

Couche Application​

Le module Application contient la logique métier centrale :

  • Documents : Gestion des documents et métadonnées
  • Forms : Gestion des formulaires
  • Views : Gestion des vues et requêtes
  • Workflows : Moteur de workflow (dans module séparé)
  • Agents : Tâches planifiées et automatisations
  • Archives : Archivage des documents

Composants principaux :

  • IDocumentManager : CRUD et logique métier des documents
  • IFormManager : Gestion des définitions de formulaires
  • IViewManager : Exécution des vues et requêtes
  • IProcessInstanceManager : Instances de processus workflow

Couche Web​

La couche Web expose l'application via HTTP :

  • Web.Model : Application ASP.NET principale (Framework 4.8)
  • Controllers/Pages : Contrôleurs et pages web
  • API : Endpoints API REST
  • SignalR : Communication temps réel

L'application web utilise OWIN pour héberger SignalR et d'autres middlewares.

Couche Studio​

Le Studio est l'outil de configuration desktop (WinForms) :

  • Interface de modélisation des formulaires
  • Éditeur de workflows
  • Configuration des vues
  • Gestion des paramètres

Il utilise la même couche métier (Application) que l'application web.

Gestion multi-base de données​

L'architecture supporte un modèle multi-tenant avec une base de données par application cliente :

services.AddDbContext<ApplicationContext>(ConfigureApplicationContext);

private static void ConfigureApplicationContext(
    IServiceProvider serviceProvider,
    DbContextOptionsBuilder options)
{
    var profile = serviceProvider.GetRequiredService<ApplicationProfile>();
    options.UseSqlServer(profile.ConnectionString);
}

Le ApplicationProfile contient les informations de connexion spécifiques à chaque application/tenant.

Bases de données​

  • Base Annuaire (Directory) : Une base commune contenant utilisateurs, rôles, organisations
  • Bases Application : Une base par application métier contenant documents et données métier

Compatibilité et migration​

L'architecture permet une migration progressive :

  • Ancien code ASP.NET Framework coexiste avec nouveaux composants
  • Injection de dépendances intégrée via adaptateurs (AspNetDependencyInjection)
  • Entity Framework Core utilisé même sur .NET Framework 4.8
  • Préparation pour migration future vers .NET moderne

Bonnes pratiques​

Enregistrement de services​

Utiliser les méthodes TryAdd* pour éviter les enregistrements multiples :

services.TryAddScoped<IDocumentManager, DocumentManager>();

Organisation des startups​

Chaque module expose une méthode d'extension sur IApsAppBuilder :

public static IApsAppBuilder AddMyModule(this IApsAppBuilder builder)
{
    // Configuration du module
    return builder.AddStartupExtensions("MyModule");
}

Dépendances entre modules​

Les dépendances entre modules sont explicites via les appels de méthodes d'extension :

apsAppBuilder
    .AddKernel()              // Kernel en premier
    .AddDirectory()           // Directory dépend de Kernel
    .AddApplication()         // Application dépend de Directory
    .AddApplicationApi();     // API dépend d'Application

Références​