Добрый день.
Мой солюшн состоит из 3-х проектов.
1. Есть проект ASP.NET клиентский с веб-формами.
2. Есть проект, отвечающий за работу с БД (выборка, запись, бизнес логика).
3. Есть проект с кастом контролами.
Задумал я хранить кое-какие данные в глобальной переменной, т.е. постоянно (ее значение должно сохраняться между всеми запросами и жить пока жива сессия).
В проекте 1 такую переменную сделать без проблем - записать в Session.
Но я захотел это сделать в проекте 2, а из него нет доступа к объекту Session, не получается. Как быть?
Попробовал перенести все классы и модули в папку App_Code проекта 1, но обнаружил, что отсюда нет доступа к Session.
Интересно, что в проекте 3 до Session можно достучаться через Page.Session.
Не мог бы кто-нибудь объяснить, как правильно реализовать хранение, скажем строки со всеми таблицами и их полями в проекте 2? И почему в технологии ASP.NET такие трудности с доступом к Session из разных мест?
Заранее спасибо.

Коллеги, ну, серьезно, глобальные переменные - это удобно, что угодно можно хранить.
Я храню Session("UserID") после авторизации и тд и тп. В ASP.NET появилось понятие "приложение" и это удобно.
Через параметры, конечно-то, понятно. Но я просто не понимаю, почему в коде страницы я могу обратиться к Session, в Global.asax я тоже могу обратиться к Session, а в модуле, вынесенным в отдельную папку app_code я этого сделать не могу.
Ведь любая процедура вызывается из него в контексте какой-то сессии.
Может быть, можно как-то через Context.Session или типа того...

Обнаружил способ:
HttpContext.Current.Session

Коллеги,
UserID, хранимый в Session - это удобно. Вне зависимости от других вариантов.
В Session также я храню строку соединения с БД (да, в моем проекте каждый пользователь может создать/открыть произвольную БД, наподобие того как в Ворде открывается произвольный файл для работы).
А также и массу других удобных глобальных переменных уровня приложения (в рамках кокретной сессии).
Например, список всех таблиц и их полей также удобно хранить в Session. Чтобы функции FieldExists, TableExists работали быстро, без запросов в БД. Да, и что там говорить... любой кеш из БД можно хранить в Сессии.
И в этом случае как раз нужен доступ к сессии из ДДЛ (проекта бизнес-логики), что очень удобно.
А что касается "это зло", "бред" - да, это просто предвзятости и догмы. Ну, а какие минусы использования Session? Уж, не считаете ли вы память, господа?! Или ресурсы сервера? Как это... несовременно. При современном развитии железного дела...
Даже несмотря на то, что одновременных пользователей может быть тысячи более, IIS не споткнется от того, что в Session будет храниться несколько переменных типа UserID и даже длинных строк со списком всех полей и таблиц БД. Справится!

МСУ ,
авторТип «веб сайт» на помойку, забудь про app_code.
Ну, а что взамен вы предлагаете? MVC?

> Field в базе уже не Exists а в сесси он еще да Exists, и наоборот
Все давно продумано, и это тоже.

>пару GB активных данных
До этого не дойдет. К тому же, уверен, этот параметр уможно увеличить при необходимости.
Я не пихаю датасеты в сессию (хотя в разумных пределах и их небольшом объеме и это будет удобно), я говорил о строке со списком таблиц. Она не много места занимает.

>А трафик, который будет постоянным, в не зависимости от надобности
Трафик получается при перекачке инфы с клиента на сервер и наоборот, т.е. если инфа содержится в form, querystring, viewstate гоняется туда-сюада (почем зря). А вот как раз в отношении серверных переменных, хранимых в Session трафика никакого не нет -все всегда остается на сервере.

Ладно, господа, не буду с вами сильно спорить, если вы так не любите хранение переменных в сессии, если вам так нравится экономить память сервера, то продолжайте и дальше не использовать Session. А ваши знания об этом считайте сокровенными, но я лично, считаю эти догмы уже устаревшими.