Quand utiliser l'attribut FromService

J’ai récemment découvert l’attribut [FromServices], qui fait partie de .Net Core depuis la première version.

L’attribut [FromServices] permet l’injection de dépendances au niveau des méthodes dans les contrôleurs Asp.Net Core.

Voici un exemple :

public class UserController : Controller
{
    private readonly IApplicationSettings _applicationSettings;

    public UserController(IApplicationSettings applicationSettings)
    {
        _applicationSettings = applicationSettings;
    }

    public IActionResult Get([FromService]IUserRepository userRepository, int userId)
    {
        //Do magic
    }
}

Pourquoi utiliser l’injection au niveau des méthodes plutôt que l’injection par constructeur ? L’explication courante est que lorsqu’une méthode a besoin de dépendances et qu’elle n’est utilisée nulle part ailleurs, c’est un candidat pour utiliser l’attribut [FromService].

Steven de StackOverflow a publié une réponse contre l’utilisation de l’attribut [FromService] :

Pour moi, l’utilisation de ce type d’injection de méthode dans les actions du contrôleur est une mauvaise idée, car :

– L’attribut [FromServices] peut être facilement oublié, et vous ne le découvrirez que lorsque l’action est appelée (au lieu de le découvrir au démarrage de l’application, où vous pouvez vérifier la configuration de l’application)

– Le besoin de s’éloigner de l’injection par constructeur pour des raisons de performance est une indication claire que les composants injectés sont trop lourds à créer, tandis que les constructeurs d’injection doivent être simples, et la création de composants devrait donc être très légère.

– Le besoin de s’éloigner de l’injection par constructeur pour éviter que les constructeurs ne deviennent trop volumineux est une indication que vos classes ont trop de dépendances et deviennent trop complexes. En d’autres termes, avoir de nombreuses dépendances est une indication que la classe viole le Principe de Responsabilité Unique. Le fait que vos actions de contrôleur puissent facilement être divisées sur différentes classes est la preuve qu’un tel contrôleur n’est pas très cohésif et, par conséquent, une indication d’une violation du SRP.

Donc, au lieu de cacher le problème racine avec l’utilisation de l’injection de méthode, je recommande l’utilisation de l’injection par constructeur comme seul modèle d’injection ici et de rendre vos contrôleurs plus petits. Cela peut signifier, cependant, que votre schéma de routage devient différent de votre structure de classe, mais c’est parfaitement correct et complètement supporté par ASP.NET Core.

Du point de vue de la testabilité, d’ailleurs, cela ne devrait vraiment pas avoir d’importance s’il y a parfois une dépendance qui n’est pas nécessaire. Il existe des modèles de test efficaces qui résolvent ce problème.

Je suis d’accord avec Steven ; si vous devez déplacer vos dépendances de votre contrôleur vers la méthode parce que la classe construit trop de dépendances, il est temps de diviser le contrôleur. Vous violez presque certainement le SRP.

Le seul cas d’usage que je vois avec l’injection de méthode est la liaison tardive lorsqu’une dépendance n’est pas prête à la construction du contrôleur. Sinon, il est préférable d’utiliser l’injection par constructeur.

Je dis cela parce qu’avec l’injection par constructeur, la classe sait à la construction si les dépendances sont disponibles. Avec l’injection de méthode, ce n’est pas le cas, on ne sait pas si les dépendances sont disponibles jusqu’à ce que la méthode soit appelée.