Как разрешить URL-адрес приложения из фонового потока в ASP.NET MVC?

Приложение разбивается на два потока; основное веб-приложение и дополнительный поток, используемый для асинхронной обработки событий. Дополнительный поток получает событие, в котором ему необходимо отправить электронное письмо с полным URL-адресом основного приложения (плюс дополнительные аргументы маршрута) внутри него.

Например. http://Server.com/App/RouteData?AdditionalArguments

Конечно, фоновый поток не может позволить себе роскошь использовать HttpContext.Current для разрешения URL-адреса, потому что нет запроса. Нет HttpRequest, нет HttpContext...

Я обнаружил, что большинство методов, которые ASP.NET (даже с MVC) использует для создания URL-адресов, основаны на HttpContext. Существует ли способ создать полный URL-адрес приложения в ASP.NET без использования HttpContext или любых его производных?

Я ищу потокобезопасный метод, например:

UrlHelper.GetApplicationtUrl()

Любые идеи? Ваши предложения очень ценятся.


thread-safety asp.net asp.net-mvc httpcontext
person Nautic20    schedule 09.08.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

У меня была именно эта проблема. В итоге я сохранил URL-адрес в файле web.config. Я сделал так:

<appSettings>
  <!-- Urls -->
  <add key="AppDomain" value="http://localhost:1273/" />
  <add key="ConfirmUrl" value="http://localhost:1273/Auth/Confirm/?code={0}" />
</appSettings>

и назвал это так на сервисном уровне:

string confirmUrl = string.Format(ConfigurationManager.AppSettings["ConfirmUrl"], confirmCode);
person Shawn Mclean    schedule 09.08.2011
comment
После долгих экспериментов я пришел к выводу, что это лучшее решение. Использование System.Web.Mvc.UrlHelper в Application_Start для поиска URL-адреса приложения, а затем назначение его статической переменной в синглтоне или передача его в качестве аргумента конструктора с использованием внедрения зависимости также работает. Однако при использовании этого решения возникают непредвиденные сбои, такие как получение базового URL-адреса прокси-сервера для балансировки нагрузки. Конфигурация кажется лучшим решением, потому что адрес целевого сервера (и протокол) не всегда может быть определен во время выполнения. Лучше заранее настроить. Спасибо Шон :) - person Nautic20; 18.08.2011

arrow_upward
0
arrow_downward

Если вы не можете просто использовать файл конфигурации, при создании потока используйте делегата ThreadStart, чтобы предоставить базовую информацию, необходимую для нового потока.

person Jon    schedule 09.08.2011
comment
Я тоже думал об этом, но что, если что-то, кроме веб-запроса, вызовет метод службы? Или что-то вроде рабочей роли для Windows Azure. (ну во всяком случае для моего случая). - person Shawn Mclean; 10.08.2011
comment
Согласен с @Shawn Mclean. Подходя к ситуации с этого маршрута, идеальное время для вызова HttpContext (для получения базового URL-адреса) не будет ThreadStart, потому что это снова предполагает, что у вас есть ресурсы, которые могут быть недоступны в это время. Я больше предпочитал получать базовый URL-адрес в Application_Start; это происходит во время запроса и в то же время, когда я подписываю событие на обработчик событий. - person Nautic20; 17.08.2011