Langage de programmation - Wolverine

Les premiers pas

Consultez également le code de démarrage rapide complet sur GitHub.

Pour une première application, construisez un système de suivi des incidents très simple pour votre propre usage. Si vous lisez cette page web, il y a fort à parier que vous travaillez déjà avec un système de suivi des incidents.

Démarrons un nouveau projet d'API web pour ce nouveau système avec :

dotnet new webapi

Ensuite, ajoutons Wolverine à notre projet avec :

dotnet add package WolverineFx

Pour commencer, nous allons simplement créer deux points de terminaison d'API acceptant une requête POST du client :

Créer un nouveau billet, l'enregistrer et envoyer un courriel au personnel interne ;
Attribuer un ticket à un utilisateur existant et lui envoyer un e-mail l'informant qu'il a du travail à faire.

Les deux commandes pour les points de terminaison POST sont les suivantes :



public record CreateIssue(Guid OriginatorId, string Title, string Description);

 
public record AssignIssue(Guid IssueId, Guid AssigneeId);

Passons directement au fichier Program.cs de notre nouveau service Web :




using JasperFx;

using Quickstart;

using Wolverine;

 
var builder = WebApplication.CreateBuilder(args);

 
// L'inclusion presque inévitable de Swashbuckle :)

builder.Services.AddEndpointsApiExplorer();

builder.Services.AddSwaggerGen();

 
// Pour l'instant, cela suffit pour intégrer Wolverine dans votre application, mais il y aura *beaucoup* d'autres options plus tard bien sûr

builder.Host.UseWolverine();

 
// Certains services en mémoire pour notre application, la seule chose comptant pour l'instant est qu'il s'agit de systèmes construits par le conteneur IoC de l'application

builder.Services.AddSingleton<UserRepository>();

builder.Services.AddSingleton<IssueRepository>();

 
var app = builder.Build();

 
// Un point de terminaison pour créer un nouveau problème qui délègue à Wolverine en tant que médiateur

app.MapPost("/issues/create", (CreateIssue body, IMessageBus bus) => bus.InvokeAsync(body));

 
// Un point de terminaison pour attribuer un problème à un utilisateur existant qui délègue à Wolverine en tant que médiateur

app.MapPost("/issues/assign", (AssignIssue body, IMessageBus bus) => bus.InvokeAsync(body));

 
// Inclusion de Swashbuckle

app.UseSwagger();

app.UseSwaggerUI();

 
app.MapGet("/", () => Results.Redirect("/swagger"));

 
// Choisissez d'utiliser JasperFx pour l'analyse de la ligne de commande afin de débloquer les outils de diagnostic et d'utilitaires intégrés dans votre application Wolverine

return await app.RunJasperFxCommands(args);

Conseil

IMessageBus est le point d'entrée de toute invocation, publication ou planification de messages. Presque tout l'exécution démarre avec ce service. Wolverine enregistre IMessageBus comme service de portée dans le conteneur DI de votre application, dans le cadre du mécanisme UseWolverine().

Bien, revenons à ce que nous avons décrit précédemment :

Nous avons intégré Wolverine au nouveau système via l'appel à IHostBuilder.UseWolverine().
Nous avons enregistré les services UserRepository et IssueRepository.
Nous avons créé quelques points de terminaison d'API minimale.

Les deux fonctions de l'API Web délèguent directement à la méthode IMessageBus.InvokeAsync() de Wolverine. Dans cette méthode, Wolverine dirige la commande vers le gestionnaire approprié et l'appel en ligne. En résumé, voici le fichier de gestionnaire complet de la commande CreateIssue :



namespace Quickstart;

 
public class CreateIssueHandler

{

    private readonly IssueRepository _repository;

 
    public CreateIssueHandler(IssueRepository repository)

    {

        _repository = repository;

    }

 
    // Le message d'événement IssueCreated renvoyé sera publié en tant que nouveau message «en cascade» par Wolverine 

     // après que le message d'origine et tout middleware associé aient réussi

    public IssueCreated Handle(CreateIssue command)

    {

        var issue = new Issue

        {

            Title = command.Title,

            Description = command.Description,

            IsOpen = true,

            Opened = DateTimeOffset.Now,

            OriginatorId = command.OriginatorId

        };

 
        _repository.Store(issue);

 
        return new IssueCreated(issue.Id);

    }

}

Nous espérons que que ce code est assez simple, mais abordons ce que vous ne voyez pas dans ce code ou dans le code initial du programme ci-dessus.

Wolverine utilise une convention de nommage pour détecter automatiquement les actions des gestionnaires de messages dans l'assembly de votre application. Nous n'avons donc jamais eu besoin d'enregistrer explicitement CreateIssueHandler. Wolverine ne nécessite pas l'utilisation d'interfaces ou d'attributs de marqueur pour détecter les gestionnaires.

INFO

Ces conventions ne sont que quelques-unes des façons dont Wolverine évite d'interférer avec le code de votre application tout en permettant aux développeurs d'écrire du code plus concis et découplé.

Comme mentionné précédemment, on souhaite que l'API crée un courriel à chaque nouvelle demande. Dans ce cas, nous avons choisi de faire en sorte que la génération et l'envoi de courriel s'effectuent dans un second gestionnaire de messages, exécuté après la commande initiale. Vous remarquerez également que la méthode CreateIssueHandler.Handle() renvoie un événement IssueCreated. Lorsque Wolverine détecte qu'un gestionnaire crée ce que nous appelons un message en cascade, il publie l'événement IssueCreated dans une file d'attente en mémoire après l'exécution réussie du gestionnaire de messages initial. L'avantage de cette méthode est que le processus de génération et d'envoi de courriels, plus lent, s'effectue en arrière-plan, au lieu de retarder l'appel initial au service Web.

Le message d'événement IssueHandled est traité par ce code :




public static class IssueCreatedHandler

{

    public static async Task Handle(IssueCreated created, IssueRepository repository)

    {

        var issue = repository.Get(created.Id);

        var message = await BuildEmailMessage(issue);

        using var client = new SmtpClient();

        client.Send(message);

    }

 
    // Ceci est une petite méthode d'aide que j'ai rendue publique

    // Wolverine n'exposera pas cela en tant que gestionnaire de messages

    internal static Task<MailMessage> BuildEmailMessage(Issue issue)

    {

          // Créez un message électronique basé sur un modèle, avec une méthode asynchrone pour rechercher 

          // des données supplémentaires, afin de pouvoir présenter un gestionnaire Wolverine désynchronisée.

        return Task.FromResult(new MailMessage());

    }

}

Vous remarquerez que Wolverine vous permet d'utiliser des méthodes statiques comme actions de gestionnaire. Notez également que la méthode Handle() prend un paramètre pour IssueRepository. Wolverine suppose toujours que le premier argument d'une méthode de gestionnaire est le type de message, mais les autres arguments sont déduits comme étant des services du conteneur IoC sous-jacent du système. En prenant en charge l'injection de méthodes de cette manière, Wolverine est en mesure de réduire encore davantage le code complexe imposé par les autres outils .NET.

Vous pourriez penser que cela ressemble au comportement d'injection de méthodes classique de l'API Minimal dans .NET 6, et c'est le cas. Mais nous tenons à souligner que Wolverine disposait de ce comportement bien avant l'équipe ASP.NET.

Cette page présente l'utilisation de base de Wolverine, comment l'intégrer aux applications .NET et quelques rudiments d'utilisation de gestionnaire. Bien sûr, tout cela était local et utilisait la mémoire, et Wolverine peut faire bien plus. Plongez plus profondément et apprenez-en davantage sur ses autres fonctionnalités de gestionnaires et de messages.

Dernière mise à jour : Jeudi, le 21 août 2025

Section courante

A propos

Section administrative du site

Les premiers pas

Conseil

INFO