L'injection de dépendances dans ASP.NET MVC 3 filtres d'actions. Quel est le problème avec cette approche?

Voici la configuration. Dire que j'ai un peu d'action, filtre a besoin d'une instance d'un service:

public interface IMyService
{
   void DoSomething();
}

public class MyService : IMyService
{
   public void DoSomething(){}
}

J'ai ensuite une ActionFilter qui a besoin d'une instance de ce service:

public class MyActionFilter : ActionFilterAttribute
{
   private IMyService _myService; //<--- How do we get this injected

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
       _myService.DoSomething();
       base.OnActionExecuting(filterContext);
   }
}

MVC 1/2 l'injection de dépendances dans l'action des filtres était un peu d'une douleur dans le cul. L'approche la plus commune est d'utiliser un appelant d'action comme on peut le voir ici: http://www.jeremyskinner.co.uk/2008/11/08/dependency-injection-with-aspnet-mvc-action-filters/ La motivation principale derrière cette solution de contournement a été parce que cette approche suivante a été considéré comme bâclée et le couplage avec le conteneur:

public class MyActionFilter : ActionFilterAttribute
{
   private IMyService _myService;

   public MyActionFilter()
      :this(MyStaticKernel.Get<IMyService>()) //using Ninject, but would apply to any container
   {

   }

   public MyActionFilter(IMyService myService)
   {
      _myService = myService;
   }

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
       _myService.DoSomething();
       base.OnActionExecuting(filterContext);
   }
}

Ici nous sommes à l'aide du constructeur d'injection et de surcharger le constructeur à utiliser le conteneur et injecter le service. Je suis d'accord que ne couplent le récipient avec le ActionFilter.

Ma question est: est-ce Maintenant dans ASP.NET MVC 3, où nous avons une abstraction du récipient utilisé (par le biais de la DependencyResolver) sont tous ces cerceaux-elle encore nécessaire? Permettez-moi de démontrer:

public class MyActionFilter : ActionFilterAttribute
{
   private IMyService _myService;

   public MyActionFilter()
      :this(DependencyResolver.Current.GetService(typeof(IMyService)) as IMyService)
   {

   }

   public MyActionFilter(IMyService myService)
   {
      _myService = myService;
   }

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
       _myService.DoSomething();
       base.OnActionExecuting(filterContext);
   }
}

Maintenant, je sais que certains puristes pourraient se moquer de cela, mais sérieusement, quel serait l'inconvénient? C'est toujours vérifiable que vous pouvez utiliser le constructeur qui prend un IMyService au temps de test et d'injecter une maquette au service de cette façon. Vous n'êtes pas lié à la mise en œuvre des DI conteneur puisque vous êtes à l'aide de la DependencyResolver, alors y at-il des inconvénients à cette approche?

D'ailleurs, voici une autre bonne approche pour ce faire dans MVC3 à l'aide de la nouvelle IFilterProvider interface: http://www.thecodinghumanist.com/blog/archives/2011/1/27/structuremap-action-filters-and-dependency-injection-in-asp-net-mvc-3

  • Merci pour les liens vers mon post :). Je pense que ce serait bien. Malgré les articles de mon blog plus tôt cette année, je ne suis pas un grand fan de la DI-elles incluses dans MVC 3 et les ont pas été à l'aide de ces derniers temps. Il semble que le travail, mais se sent un peu maladroit parfois.
  • Si vous utilisez Ninject, cela pourrait être une approche possible: stackoverflow.com/questions/6193414/...
  • +1, bien que le service locator est considéré comme un anti-modèle par beaucoup de gens, je pense que je préfère votre approche sur les Marques pour sa simplicité et le fait que la dépendance est résolu en un seul endroit, le conteneur IOC, tandis que dans la Marque de l'exemple que vous auriez à résoudre en deux endroits, dans le programme d'amorçage et lors de l'enregistrement de l'filtres globaux, qui se sent mal.
  • vous pouvez toujours utiliser le "DependencyResolver.Actuel.La méthode GetService(Type) n'importe quand vous voulez.
InformationsquelleAutor BFree | 2011-08-25
  1. 30

    je ne suis pas positif, mais je crois que vous pouvez simplement utiliser un constructeur vide (pour les attribut partie) et ensuite avoir un constructeur qui fait injecte la valeur (pour le filtre partie).*

    Modifier: Après un peu de lecture, il semble que la façon de le faire est par la propriété d'injection:

    public class MyActionFilter : ActionFilterAttribute
{
    [Injected]
    public IMyService MyService {get;set;}

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        MyService.DoSomething();
        base.OnActionExecuting(filterContext);
    }
}

    Concernant la pourquoi ne pas utiliser un Localisateur de Service question: Il la plupart du temps simplement réduit la souplesse de votre dépendance à l'injection. Par exemple, si vous avez été l'injection d'un service d'enregistrement, et vous avez voulu donner automatiquement le service d'enregistrement de nom de la classe c'est d'être injecté dans? Si vous utilisez constructeur d'injection, qui serait de l'excellent travail. Si vous êtes à l'aide d'un Solveur de Dépendances/Localisateur de Service, vous serez hors de la chance.

    Mise à jour

    Depuis cet été admis que la réponse, j'aimerais bien aller sur le dossier de dire que je préfère Marque Seeman l'approche de parce qu'il sépare l'Action de Filtre responsabilité à l'écart de l'Attribut. En outre, Ninject de MVC3 extension a de très puissants moyens pour configurer des filtres d'actions via des liaisons. Consultez les références suivantes pour plus de détails:

    Mise à jour 2

    Comme @usr souligné dans les commentaires ci-dessous, ActionFilterAttributes sont instanciés lorsque la classe est chargée, et ils durent toute la durée de vie de l'application. Si le IMyService interface n'est pas censé être un Singleton, alors il finit par être une En Captivité Dépendance. Si sa mise en œuvre n'est pas thread-safe, vous pourriez être dans un beaucoup de douleur.

    Chaque fois que vous avez une dépendance avec une durée de vie plus courte que celle de votre classe de durée de vie prévue, il est sage d'injecter une usine à produire que la dépendance à la demande, plutôt que de l'injecter directement.

    • Re votre commentaire sur le manque de souplesse: Derrière la DependencyResolver est en fait un conteneur IOC de conduite, de sorte que vous pouvez ajouter une logique personnalisée que vous voulez à droite là lors de la construction d'un objet. Pas sûr que je suivez votre point de vue.....
    • Lors de l'appel de DependencyResolver.GetService, la méthode de reliure a aucune idée de ce qui classe cette dépendance est d'être injecté dans. Que faire si vous voulez créer un autre IMyService pour certains types d'action des filtres? Ou, comme je l'ai dit dans ma réponse, et si vous vouliez un argument à la MyService mise en œuvre de dire dans quelle classe il a été injecté dans (ce qui est utile pour les bûcherons)?
    • OK, j'ai fait un peu de déconner, et vous avez droit à 100%, il n'y a aucun moyen d'obtenir le "contexte" dont la résolution actuelle qui se passe, donc oui c'est un inconvénient. Bon point. Je dirais, cependant, que l'ajout d'un Injecter de l'attribut est laid en tant que bien que les liens de votre service, à la mise en œuvre d'un conteneur ainsi, alors que mon DependencyResolver approche ne fonctionne pas. Je vais laisser cette question ouverte, pour un peu, je suis juste curieux d'entendre d'autres opinions. Merci!
    • Je suis d'accord que la propriété de l'injection est moins-que-idéales. N'hésitez pas à laisser la question ouverte aussi longtemps que vous le souhaitez. Je suis intéressé à entendre d'autres solutions. Concernant la Injected attribut, vous pouvez spécifier votre propre attribut via le NinjectSettings.InjectAttribute de la propriété. Cela rend plus facile de garder votre Ninject références contenues dans votre DI code d'installation.
    • Je déteste poster des commentaires sur d'anciennes questions, mais en ce qui concerne la question "Que faire si vous voulez un argument à la mise en œuvre (c'est à dire les bûcherons)", il a été mon expérience que vous pouvez toujours utiliser le service locator motif de cette manière. Juste avoir le service localisateur de retour de l'enregistreur de l'usine. Ensuite, vous pouvez appeler LoggerFactory.Créer(someParameter) pour injecter les paramètres dont vous avez besoin. Je crois que ce qui est communément appelé l'abstrait modèle de fabrique.
    • Merci pour le commentaire. L'idée de la "spéciale" argument question a été spéciale que votre argument pourrait être automatiquement fourni par l'intermédiaire de la résolution des dépendances. L'exemple en question est un enregistreur de frappe, qui prend souvent la classe qui l'utilise comme paramètre. Comme vous le dites, vous pourriez avoir toutes les classes de construire sa propre enregistreur en appelant ServiceLocator.Get<LoggerFactory>().Create(typeof(Foo)), mais cela vous ouvre à une forte probabilité de copier-coller des erreurs. Si vous ne modifiez pas le type de param, Le journal pourrait-on dire, un message d'erreur est produit par un Foo quand elle est produite par un Bar.
    • Un enregistreur de cas est spécial à cet égard, je pense que, au moins en fonction de comment vous le faites. Pour moi, chaque classe qui a besoin de journalisation obtient une ILoggerFactory injectés via DI, puis appelle LoggerFactory.Create(this); dans son constructeur. Parce que l'instruction est l'auto-référencement par nature, il n'y a pas de copier/coller des erreurs pour en parler.
    • L'Action des filtres sont partagés entre les demandes dans MVC 3. C'est très thread-dangereux.
    • Je vous remercie de votre commentaire, mais je ne pense pas que la réponse méritée votre downvote. Ce code n'est pas intrinsèquement "très thread-dangereux". C'est seulement de ne pas "thread-safe" si MyService.DoSomething() n'est pas thread-safe. Il n'a pas d'introduire une nouvelle thread-des questions de sécurité qui n'étaient pas déjà dans le cas des OP code. Il n'est ni moins thread-safe de la Marque Seeman de réponse. Cependant, j'ai fait la mise à jour de la réponse à indiquer que l'action des filtres sont partagés entre les demandes, donc vous avez besoin pour regarder dehors pour les Captifs Dépendances.
    • OK, j'ai enlevé le downvote. Il n'était pas approprié. Je vais supprimer ces commentaires par la suite. La MVC3 faire des changements de filtres singletons est, dans mon esprit, sans valeur positive et très dangereux. Mon intention était de sauver les autres des difficultés lorsqu'ils découvrent que dans la production.
    • Méfiez-vous, à l'aide de la [Injected] attribut, vous prenez une dépendance sur votre conteneur dans votre action de filtre. Je ne suis pas familier avec beaucoup de DI conteneurs, mais LightInject, lorsqu'il est configuré pour le Web API, va injecter un service en action des filtres sans avoir à utiliser n'importe quel type de [Injected] attribut.

    InformationsquelleAutor StriplingWarrior
  2. 91

    Oui, il y a des inconvénients, comme il y a beaucoup de problèmes avec IDependencyResolver lui-même, et à ceux que vous pouvez ajouter l'utilisation d'un Singleton Localisateur de Service, ainsi que Bâtard D'Injection.

    Une meilleure option est de mettre en place le filtre de classe normale dans laquelle vous pouvez injecter selon les services que vous souhaitez:

    public class MyActionFilter : IActionFilter
{
    private readonly IMyService myService;

    public MyActionFilter(IMyService myService)
    {
        this.myService = myService;
    }

    public void OnActionExecuting(ActionExecutingContext filterContext)
    {
        if(this.ApplyBehavior(filterContext))
            this.myService.DoSomething();
    }

    public void OnActionExecuted(ActionExecutedContext filterContext)
    {
        if(this.ApplyBehavior(filterContext))
            this.myService.DoSomething();
    }

    private bool ApplyBehavior(ActionExecutingContext filterContext)
    {
        //Look for a marker attribute in the filterContext or use some other rule
        //to determine whether or not to apply the behavior.
    }

    private bool ApplyBehavior(ActionExecutedContext filterContext)
    {
        //Same as above
    }
}

    Remarquez comment le filtre examine la filterContext pour déterminer si oui ou non le comportement doit être appliquée.

    Cela signifie que vous pouvez toujours utiliser les attributs de contrôler si oui ou non le filtre doit être appliqué:

    public class MyActionFilterAttribute : Attribute { }

    Cependant, maintenant que l'attribut est complètement inerte.

    Le filtre peut être composé avec la dépendance et ajouté les filtres globaux mondiaux.asax:

    GlobalFilters.Filters.Add(new MyActionFilter(new MyService()));

    Pour un exemple plus détaillé de cette technique, bien qu'appliquées à ASP.NET l'API Web au lieu de la MVC, voir cet article: http://blog.ploeh.dk/2014/06/13/passive-attributes

    • Merci pour votre réponse, mais n'en déplaise, tous vos liens pointez simplement arguments philosophiques sur l'attribution de noms de modèles. Après avoir lu toutes vos réponses à d'autres questions que vous avez lié, et les articles du blog, je ne vois pas de problèmes concrets, qui découlerait de l'utilisation de mon approche. Ajoutez à cela que maintenant tout ActionFilter-je utiliser dans mon application, j'ai besoin de ne pas oublier d'ajouter les filtres globaux, et je dirais que cette approche pourrait conduire à des erreurs de son propre. Si vous pouvez donner un exemple concret de la façon dont mon approche peut conduire à des erreurs, alors je vais vous avouer que je suis thickheaded 🙂
    • Vous m'avez demandé ce que les inconvénients seraient: les inconvénients sont une diminution de la maintenabilité de votre base de code, mais qui se sent à peine béton. C'est quelque chose qui se glisse sur vous. Je ne peux pas dire que si vous faites ce que vous proposez de le faire, vous aurez une condition de course, ou le CPU surchauffe, ou les chatons vont mourir. Cela ne va pas arriver, mais si vous ne suivez pas les bon modèles de conception et d'éviter les anti-modèles, votre code de la pourriture et de quatre ans à partir de maintenant, vous aurez envie de réécrire l'application à partir de zéro (mais vos parties prenantes ne vous laisse pas).
    • Juste assez. Je suis d'accord avec vous, que si je suis en train de construire un tout usage ActionFilter qui peuvent être utilisés dans les projets, alors oui, cela peut être un anti-modèle, le constructeur par défaut peut être appelé, et si DependencyResolver n'est pas utilisé, vous obtiendrez quelques erreurs étranges. Cependant 1)votre approche nécessite un enregistrement avec le GlobalFilters qui peut conduire à le même problème que j'ai énoncé ci-dessus, et 2)Que si cette action de filtre n'est pas utilise dans les applications? Si ce filtre d'actions internes? Toujours aussi mauvais?
    • Dans le long terme, code sur la base de l'état statique est juste plus difficile à maintenir. C'est à des données globales et nous avons connu pour ~40 ans que c'est mauvais. Il n'y a pas moyen de contourner cela...
    • Encore une question (je ne suis pas difficile, je suis vraiment curieux). Comment voulez-vous mettre en œuvre ces méthodes vous en commentaire? Ne seriez-vous pas la duplication de la logique qui est déjà dans la base ActionFilterAttribute classe? Semble que beaucoup de travail juste pour éviter d'avoir un constructeur par défaut de la classe la consommation du service...
    • +1 pour montrer comment séparer l'action du filtre de code à partir de l'attribut code. Je préfère cette méthode uniquement pour l'amour de la séparation des préoccupations. J'apprécie l'OP est frustré par le manque de précision sur le "quel est le problème avec cette" partie de la question. Il est facile d'appeler quelque chose d'un anti-modèle, mais quand son code spécifique traite de la plupart des arguments contre l'anti-modèle (unité-la testabilité, la liaison via la configuration, etc.), il serait bon de savoir que pourquoi avec ce modèle, le code de pourrir plus vite que les plus "purs" code peut. Non pas que je suis en désaccord avec vous. J'ai beaucoup apprécié votre livre, BTW.
    • Par la voie, Remo Gloor a fait quelques excellentes choses avec le MVC3 extension pour Ninject. github.com/ninject/ninject.web.mvc/wiki/... explique comment vous pouvez utiliser Ninject liaisons de définir une action de filtre est appliqué à des contrôleurs ou des actions ayant un attribut spécifique sur eux, plutôt que d'avoir à enregistrer les filtres à l'échelle mondiale. Cela permet de transférer encore plus de contrôle sur votre Ninject liaisons, qui est le point de l'ensemble de la Coi.
    • Comment mettre en œuvre les méthodes d'esquisse: la ActionDescriptor qui fait partie de la filterContext implémente ICustomAttributeProvider, de sorte que vous pouvez retirer le marqueur d'attribut à partir de là.
    • ans à partir de maintenant, vous aurez envie de réécrire l'application à partir de zéro (mais vos parties prenantes ne vous laissera pas), ou va laissez lui et les produits meurt parce que le TTM est trop long.
    • Comment MVC savoir appliquer le filtre lorsque vous décorez actions avec l'attribut? Est-il juste utiliser des conventions de nommage?
    • Il n'a pas. MVC applique le filtre à l'échelle mondiale. Note les commentaires de code, "Rechercher un marqueur de l'attribut dans la filterContext ou utilisez une autre règle pour déterminer si ou de ne pas appliquer le comportement."
    • C'est de loin mon préféré de l'approche. J'aime la Marque de blogs - ils sont toujours sur place. Le seul inconvénient de cette approche est que le filtre est évalué sur chaque action, peu importe si elle sera appliquée. Si l'on devait s'inscrire 100 de l'action mondiale des attributs, où un seul effectivement appliqué, y aurait-il un notable de performances? C'est beaucoup de réflexion appels de vérifier l'existence d'un attribut n'est-ce pas? Dans l'ensemble, je pense, de la maintenabilité et de ne pas avoir à utiliser un Cio pour atteindre DI emporte sur tout inconvénient, mais il serait intéressant de voir dans un exemple extrême.
    • Comment pensez-vous que l'ASP.NET cadre trouve et appelle les attributs de il définit? 😉
    • Je n'avais pas regardé encore, mais j'ai pensé qu'ils pourraient faire un peu de type de préalables, et postAction privé appelle après l'action a été sélectionné. À en juger par votre réponse, je suppose qu'ils sont tout simplement les enregistrer comme des filtres globaux au moment de l'exécution? Le temps d'aller creuser!
    • Si vous n'aimez pas l'échelle mondiale en ajoutant des filtres, effectuez CIO, et l'utilisation de DefaultControllerFactory.CreateController, vous pouvez effectuer les opérations suivantes (pardonnez le 1-liner, qui je ne le conseille pas): ((Controller)base.CreateController(requestContext, controllerName)).ActionInvoker = _customActionInvoker où _customActionInvoker implémente ControllerActionInvoker et vous pouvez les écraser et de contrôle GetFilters. Si vous vous souciez par exemple, le code, je vais poster une suite de réponse à Marc.

    InformationsquelleAutor Mark Seemann
  3. 6

    La solution la Marque Seemann a suggéré semble élégant. Cependant assez complexe pour un simple problème. En utilisant le cadre de la mise en œuvre de AuthorizeAttribute se sent plus naturel.

    Ma solution a été de créer un AuthorizeAttribute avec un délégué statique de l'usine à un service social mondial.asax. Il fonctionne pour tous les DI conteneur et se sent un peu mieux qu'un Localisateur de Service.

    Mondiale.asax:

    MyAuthorizeAttribute.AuthorizeServiceFactory = () => Container.Resolve<IAuthorizeService>();

    Ma classe attribut personnalisé:

    [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public class MyAuthorizeAttribute : AuthorizeAttribute
{
    public static Func<IAuthorizeService> AuthorizeServiceFactory { get; set; } 

    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        return AuthorizeServiceFactory().AuthorizeCore(httpContext);
    }
}
    • J'aime ce code, car vous n'avez pas de haut couple le Service Locator avec MyAuthorizeAttribute.
    InformationsquelleAutor Jakob