Aller au contenu principal

Structure des projets d'une solution

Une solution applicative Lagoon est organisée en projets spécialisés. La solution de démonstration Apps\Demo\Demo.sln illustre cette organisation avec les projets Demo.Client, Demo.Server, Demo.Model, Demo.Shared, Demo.Services et Demo.Batch, aux côtés des modules du framework.

Solutions du dépôt​

Le dépôt distingue les solutions par zone de travail :

SolutionRôle
Modules\Modules.slnBibliothèques du framework Lagoon.
Apps\<App>\<App>.slnSolution d'une application ou d'une application de démonstration.

Projets d'une application​

ProjetRôle
ClientApplication web cliente Blazor WebAssembly.
ServerApplication web serveur : hébergement, pages serveur, contrôleurs, authentification.
BatchApplication console pour les commandes batch.
ServicesServices partagés côté serveur.
ModelAbstraction de la base de données avec Entity Framework Core.
SharedDonnées partagées : constantes, énumérations, rôles, policies et ViewModels.

Client​

Le projet Client contient l'interface Blazor WebAssembly : pages, composants, services HTTP côté client, ressources statiques et dictionnaire de traduction de l'UI.

Dans Apps\Demo\Client\Demo.Client.csproj, le projet référence notamment :

  • Demo.Shared, pour les ViewModels, rôles, policies et constantes partagés ;
  • les modules UI Lagoon nécessaires à l'application, par exemple Lagoon.UI, Lagoon.UI.Custom, Lagoon.UI.GridView ou Lagoon.UI.Notifications.

Le point d'entrée client appelle LagoonWebAssemblyApplication.RunAsync<Main>(args). La classe Main hérite de LgCustomApplication et peut configurer les comportements globaux, les composants racine, les services client et les policies côté client.

Server​

Le projet Server héberge l'application ASP.NET Core, sert l'application Blazor WebAssembly, expose les contrôleurs API et configure l'authentification.

Dans Apps\Demo\Server\Demo.Server.csproj, le projet référence :

  • Demo.Client, pour héberger l'application WebAssembly ;
  • Demo.Services, pour accéder à la logique métier serveur ;
  • Lagoon.Server, pour l'infrastructure serveur Lagoon.

Le point d'entrée serveur appelle LagoonWebApplication.Run<Main>(args). La classe Main hérite de LgAuthApplication<ApplicationDbContext, ApplicationUser> et configure notamment le DbContext, les services, le pipeline HTTP, l'authentification, les autorisations et la mise à jour de la base de données.

Model​

Le projet Model contient la couche Entity Framework Core : ApplicationDbContext, entités, migrations et seeders.

Dans Apps\Demo\Model\Demo.Model.csproj, le projet référence Demo.Shared, Lagoon.Model et les packages EF Core utilisés par l'application. Le contexte de la démonstration est défini dans Model\Context\ApplicationDbContext.cs et hérite de LgApplicationDbContextGuid<ApplicationUser>.

Les migrations EF Core sont placées dans Model\Migrations\. La solution de démonstration contient par exemple la migration 20230412074341_Init.cs et le snapshot généré ApplicationDbContextModelSnapshot.cs.

Shared​

Le projet Shared contient les éléments consommés par plusieurs couches : ViewModels, constantes, énumérations, rôles et policies.

Dans Apps\Demo\Shared\Demo.Shared.csproj, le projet référence Lagoon.Shared. Il est utilisé par le Client et le Model, ce qui permet de partager les contrats sans dépendre des projets serveur.

Services​

Le projet Services contient les services métier côté serveur. Dans la solution de démonstration, Apps\Demo\Services\Demo.Services.csproj référence Demo.Model et Lagoon.Services.

Les services applicatifs sont enregistrés dans une classe Services\Registry.cs avec une méthode statique RegisterServices(IServiceCollection services). Le serveur et les batchs appellent ce registre depuis leur configuration.

Batch​

Le projet Batch est une application console. Dans Apps\Demo\Batch\Demo.Batch.csproj, il référence Demo.Services et Lagoon.Console.

Le point d'entrée batch est une classe Main qui hérite d'une application console Lagoon. Les commandes sont déclarées avec des attributs comme [Subcommand(typeof(UpdateDbCommand))], et les services sont enregistrés via Services.Registry.RegisterServices(services).

Dépendances entre projets​

Le schéma courant est le suivant :

APP.Shared   ──►  APP.Model  ──►  APP.Services  ──►  APP.Server
                                                 └──►  APP.Batch
APP.Shared   ──►  APP.Client

Cette organisation évite que le client dépende directement du serveur ou de la couche EF Core. Les contrats communs restent dans Shared, la persistance dans Model, la logique serveur dans Services, puis les points d'entrée dans Server et Batch.

Conventions associées​

Namespaces​

Les namespaces suivent la structure des dossiers. Par exemple, un service dans Apps\Draft\Client\Services\ utilise le namespace Draft.Client.Services.

Usings globaux​

Chaque projet possède un fichier _Usings.cs pour centraliser les global using. Les imports utilisés à l'échelle d'un projet doivent y être placés plutôt que répétés fichier par fichier.

Pages et composants​

Les pages et composants Blazor utilisent toujours deux fichiers :

MyPage.razor
@inherits LgPage
MyPage.razor.cs
namespace Demo.Client.Pages;

public partial class MyPage : LgPage
{
}

Le fichier .razor contient le markup ; le fichier .razor.cs contient le code C# de la classe partielle.

Injection de dépendances​

Les services applicatifs sont regroupés dans un fichier Services\Registry.cs par couche. Ce registre expose RegisterServices(IServiceCollection services) et utilise généralement des enregistrements directs comme AddScoped<MyService>(), sauf lorsqu'une abstraction est nécessaire.

Voir aussi​

  • Premier projet
  • La page Architecture de cette section présente la vue d'ensemble applicative.