J'ai plusieurs services d'injection de dépendance qui dépendent de choses comme le contexte http. À l'heure actuelle, je les configure comme singletons le conteneur Windsor dans le gestionnaire Application_Start, qui est évidemment un problème pour ces services.
Quel est le meilleur moyen de gérer cela? Je envisage de les faire
3 Réponses :
avec le château Windsor, vous pouvez utiliser le Cela signifie que vous pouvez simplement injecter les choses HTTP dans vos services et que le conteneur prendra soin de la bonne gestion de la vie. Toutefois, cela vous oblige également à enregistrer tous ces services (et tous les consommateurs de ces services, etc.), comme si vous les enregistrez comme des singletons, ils tiendront à des contextes escaladiens (et éventuellement disposés). < / p> perwebrequest à vie - qui devrait s'intégrer à vos besoins.
Mark, merci pour l'information - je ne savais pas au sujet de Perwebrequest. Je vérifierai.
Mark, j'ai examiné Perwebrequest, mais je ne vois toujours pas comment les services peuvent obtenir httpContext. Lorsque j'essaie d'enregistrer une instance de httpcontextbase dans le conteneur moi-même, elle échoue après la deuxième demande (puisque une instance était déjà enregistrée dans la demande précédente). Je n'ai rien trouvé sur Google Jusqu'ici ...
J'ai peut-être mal compris ce que vous essayez de faire, mais vous ne pouvez pas utiliser le httpcontext de l'application_start, car à ce stade, est pas httpcontext (perwebrequest ou non PerwebRequest). Maintenant que j'y pense, cela n'a aucun sens de tenter de contrôler la durée de vie du HttpContext à partir du conteneur DI, car cette durée de vie est déjà gérée par le cadre ASP.NET MVC. Ce que vous peut faire est de vous connecter à une icône personnalisée et de saisir le HTTPContext vous a servi à ce stade, puis utilisez une méthode d'usine pour filer tout ce qui dépend de celui-ci.
Mark: Un collègue de mine a suggéré d'accéder à httpContext.Current Propriété, sans injection ni méthodes d'usine. Ce n'est pas très di-environnement, mais on dirait que ça marche. J'ai enregistré ces services comme Perwebrequest, juste pour être du bon côté.
Tout comme Mark a dit, vous devez enregistrer ces services dépendants de HTTP, soit comme parwebRequest ou transitoire. Voici un échantillon qui montre comment enregistrer et injecter un HTTPRequest ou httpContext: à l'aide de httpeffestbasebasebaseb au lieu de httpequest Vous pouvez facilement vous moquer pour les tests.
En outre, n'oubliez pas d'enregistrer perwebrequestlifestylemodule dans votre web.config.
Merci Mauricio, c'est quelque chose que je cherchais.
Pourrait être la peine de réitérer que vous devez ajouter la ligne: conteneur.addddFacility
A partir de Windsor 2.5, FactorySupportFacility n'est plus nécessaire pour ce cas.
Mais tous les composants en fonction du contexte HTTP doivent être enregistrés comme perwebRequest ou transitoire, non? Est-il possible d'éviter cela?
Je viens de courir dans ce même problème, mais ma solution est quelque peu différente.
interface: implémentation: I Ensuite, inscrivez-vous le suis-je vraiment en train de compliquer des choses ou y a-t-il des avertissements dans ma solution? IHTTPContextProvider en tant que singleton dans le conteneur.
Je suis toujours un peu un débutant quand il s'agit de di, alors peut-être que je suis sur des choses compliquées, mais d'après ce que je peux comprendre, je ne peux pas avoir de composants singleton dépendent des composants de style de vie perwebrequest, ce qui a du sens (mais C'est ce que font tous les exemples). Dans ma solution, je dépends de httpcontext.current dans un composant isolé et je ne suis pas intéressé à tester cela. Mais tous les composants qui ont besoin d'accès au contexte HTTP peuvent obtenir cela en fonction de ihttpcontextprovider et de se moquer facilement cela au besoin.
Je devrais mentionner que, de cette manière, aucun de mes services qui dépend du contexte HTTP actuel n'a besoin d'être enregistré comme PerWebRequest / Transient.