Добрый день.

Господа, прошу вашей помощи!

Есть веб сайт, который использует некоторую библиотеку классов.
Необходимо получить доступ к текущему HttpApplication в каком-нибудь классе не передавая его как параметр в этот класс. Т.е. можно ли его вытащить через AppDomain или каким-нибудь другим способом?

Благодарю!

Дело то как раз и было в том, что пытаюсь получить доступ из другого контекста.

Я искал какое-то подобие фабрики для получения HTTPApplication
В общем, решение нашлось простое и логичное - написал свою фабрику, в которую поместил информацию, которая мне нужна в других объектах. Только не понятно, почему MS не предусмотрели стандартного аналогичного механизма.

sysprog, HttpContext.Current - статическое свойство. Оно доступно вообще из любого места приложения. Из какого "другого" контекста ты не смог его получить? И что за "фабрики для хранения информации" - так теперь называют глобальные переменные? :(

Ну вроде как "фабрика" - это один из шаблонов проектирования, так что все нормально. Насколько я знаю, аспнет-приложением, например, рулит фабрика хендлеров (IHttpHandlerFactory). Правда, я тоже не понял, как это автор реализовал...

Zakonnic, я знаю что такое фабрика, поэтому и спросил 

Да, лоханулся я с : HttpContext.Current       
Не дочитал, что он статический...  :(

Приходится на 10 языках постоянно разговаривать с программистами на одном, с клиентами на другом, с начальством на третьем и т.д. 
Прошу прощения за формулировку! 


Реализовал просто - простая фабрика классов, которая по запросу создает один экземпляр какого-то нужного известного класса и кладет это в статический Dictionary, откуда потом достает при надобности!  
С другой стороны своей реализацией упростил задачу себе же задачу, т.к. мне еще необходимо было хранить ID пользователя из БД и дополнительные поля, т.е. просто создал класс и забил его нужными свойствами.

Благодарю за внимание и помощь!

sysprog, посмотри в сторону отказа от синглтонов и перехода на StructureMap/Unity. Cтатический Dictionary - не лучший выбор.

Можно немного подробней? Интересно проблемы со статическим Dictionary!




Описано вроде красиво  Можно в сжатом виде, для чего используется, какие преимущества и недостатки?

Вы уверены, что так проще? 
По-моему проще - это создать класс юзера со всеми необходимыми полями, отнаследовав его от IPrincipal и подсунуть контексту как значение свойства User.

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

Достоинства - берет на себя управление зависимостями в проекте. Т.е. позволяет из любого места получить объект с нужным тебе интерфейсом. Примерно как твоя фабрика на Dictionary, только она создает не только один конкретный класс по ключу (интерфейсу), а еще и все объекты, от которых он зависит. И заодно берет на себя управление временем жизни - может выдавать один и тот же объект на каждый запрос (типа синглтон), может создавать каждый раз разный, может ограничивать время жизни одинм HttpRequest. Недостатки - это все-таки лишний кусок чужого кода 

Спасибо за информацию!! Знания не настолько глубоки. 
У меня правда еще MembershipProvider, нужно будет проверить получится ли таким образом юзера проинициализировать...



PashaPash, спасибо за совет. Система действиетельно интересная, но боюсь, что клиент не одобрит сторонний опенсорс. Случайно, не в курсе как с безопасностью у них дела?

Это сообщение отредактировал(а) sysprog - 22.12.2008, 20:38

Тогда бери Unity, из Microsoft Enterprise Library. Умеет то же, даже немного больше. И документация у них неплохая.