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 de méthode plutôt que l’injection de 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, alors c’est un candidat pour utiliser l’attribut [FromService].

Steven de StackOverflow a posté 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 de contrôleur est une mauvaise idée, car :

– Un tel attribut [FromServices] peut être facilement oublié, et vous ne le découvrirez que lorsque l’action sera invoqué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 de constructeur pour des raisons de performance est une indication claire que les composants injectés sont trop lourds à créer, alors que les constructeurs d’injection devraient être simples, et la création de composants devrait, par conséquent, être très légère.

– Le besoin de s’éloigner de l’injection de constructeur pour éviter que les constructeurs 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 réparties 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 conseille l’utilisation de l’injection de constructeur comme seul modèle d’injection ici et de rendre vos contrôleurs plus petits. Cela pourrait signifier, cependant, que votre schéma de routage devient différent de votre structure de classe, mais c’est parfaitement acceptable, et complètement supporté par ASP.NET Core.

Du point de vue de la testabilité, d’ailleurs, cela ne devrait pas vraiment importer 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, alors 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 lors de la construction du contrôleur. Sinon, il est préférable d’utiliser l’injection de constructeur.

Je dis cela parce qu’avec l’injection de 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.