Possible de tromper HTTPContext.Current?

Question

J'ai cette ligne de code dans un ensemble:

HttpContext.Current.Server.MapPath 

Cela fonctionne très bien si l'assemblage est utilisé dans un service Web. Mais si je le retire du service Web, il ne fonctionnera pas, car HTTPContext n'existe pas.

Est-il possible de tromper httpContext en pensant qu'il existe, vraiment juste pour obtenir la structure de chemin relatif d'un répertoire?

Je veux dire en quelque sorte créer manuellement l'objet HTTPContext, et lui assigner un répertoire de base?

Mise à jour

Y at-il une approche plus générique: HttpContext.Current.Server.MapPath

Quelque chose qui peut travailler dans executables, et quelque chose qui peut travailler dans le web?

Answer 1

HttpContext.Current « obtient ou ensembles l'objet HttpContext ». Et HttpContext a un constructeur public qui prend un HttpWorkerRequest (abstract, utilisez SimpleWorkerRequest) et vous seriez capable de fausser complètement le HttpContext.

Je suis d'accord avec les autres que vous pourriez refactoriser votre code pour supprimer cette dépendance, mais il y a des scénarios quand vous devez faux les trucs de HttpContext.Current, auquel cas cette question apparaîtraient si vous recherchez ...

Answer 2

Il me semble que vous devez conclure l'appel à HttpContext à l'intérieur d'un autre objet que vous pouvez ensuite changer en utilisant IOC pour l'objet correct dans l'environnement correct. Par exemple. quelque chose comme IMapPath en tant qu'interface et votre implémentation pourrait être HttpMapPath ou ConsoleAppMapPath, etc.

Answer 3

Un tel code est spécifique au site Web. Je me demande pourquoi cela appartient à la logique métier.

Probablement re-factoriser ce code va exclure HttpContext de la logique métier sera la meilleure solution. Par exemple, vous pouvez accepter le chemin d'accès au fichier en tant que paramètre de méthode au lieu de le résoudre dans la logique métier.

Answer 4

Nous faisons quelque chose de similaire lorsque nous écrivons des tests unitaires qui utilisent HttpContext.Current. Nous avons une interface appelée IHttpContext qui contient tout ce dont nous avons besoin du HttpContext normal. Ensuite, au lieu d'appeler HttpContext.Current, nous avons une méthode d'extension (HttpContext.Current.Make()) qui renvoie cette interface IHttpContext. Dans la méthode d'extension, nous sommes alors en mesure de décider si HttpContext.Current est utilisable, si ce n'est pas le cas, alors nous sommes en mesure de construire manuellement un objet "Testable" et de le renvoyer.

Bien sûr, cela étend à avoir à écrire IRequest, IResponse objets etc si vous les utilisez, mais je pense que c'est à prévoir

Answer 5

Je ne sais pas si cela vous aidera, mais j'ai eu un problème similaire lors de l'écriture de tests unitaires pour une application web asp.net. À un certain moment dans l'un des appels API, une propriété était définie par HttpContext.Current.XXXXX qui n'était pas dans la portée.J'ai trouvé la réponse était d'ajouter les attributs à mon test unitaire suivantes:

[TestMethod()]
[HostType ("ASP.NET")]
[UrlToTest ("http://mytestsite.com/Home.aspx")]

original article