Что вставить переменную сеанса
Использовать SpringQuery Spring:
DBObject queryCondition = new BasicDBObject();
BasicDBList values = new BasicDBList();
values.add(new BasicDBObject("A", 10));
values.add(new BasicDBObject("B", 20));
queryCondition.put("$or", values);
Query query = new BasicQuery(queryCondition);
mongoTemplate.find(query, clazz);
9 ответов
На это довольно трудно ответить, потому что это таким образом специализировано, но здесь является несколькими инструкциями, которые я использую:
- Помещенный как можно меньше в сессию.
- Определенные для пользователя выборы, которые должны только продлиться во время данного посещения, являются хорошим выбором
- часто, переменные, которые должны быть доступны для нескольких страниц в течение визита пользователя в Ваш сайт (чтобы не передавать их от страницы до страницы) также хороши, чтобы вставить сессию.
Из того, что мало Вы сказали о своем приложении, я, вероятно, выбрал бы Ваши данные из дб и попытался бы найти способы минимизировать влияние тех запросов вместо того, чтобы перегрузить сессию.
НЕ помещайте объекты пользовательского интерфейса в сессию.
кроме того, я сказал бы, что это варьируется. слишком много на сессии может замедлить Вас, если Вы не используете на сессии процесса, потому что Вы собираетесь быть сериализацией много + скорость поставщика. Кэш и Сессия должны использоваться экономно и тщательно. Только вставьте сессию, потому что Вы можете или быть удобными. Сядьте и проанализируйте, если это имеет смысл.
Не помещайте информацию о соединении с базой данных в сессию.
До кэширования я избегал бы использования сессии для кэширования, если возможный - Вы столкнетесь с проблемами, где кто-то еще изменяет данные, пользователь использует, плюс Вы не может совместно использовать кэшированные данные между пользователями. Используйте Кэш ASP.NET или некоторую другую утилиту кэширования (как Memcached или Velocity).
До того, что должно войти в сессию, что-либо, что относится ко всем окнам браузера, которые пользователь имеет открытый для Вашего сайта (вход в систему, настройки безопасности, и т.д.), должен быть на сессии. Вещи как то, какой объект просматривается/редактируется, должны действительно быть, РАЗДАЛИ переменные между экранами, таким образом, пользователь может использовать несколько окон браузера для работы с приложением (если Вы не хотели бы предотвратить это).
хранение сигналов навигации на сессиях хитро. Тот же пользователь может иметь несколько открытых окон и затем изменяется, распространены запутывающим способом. Соединения с БД не должны определенно быть сохранены. ASP.NET поддерживает пул соединения для Вас, никакая потребность обратиться к Вашему собственному колдовству. Если необходимо кэшировать материал в течение коротких периодов, и размер набора данных является относительно небольшим, изучите ViewState как возможный вариант (за счет загрузки большего количества объема на размер страницы)
Идеально, сессия в ASP должна сохранить наименьшее количество объема данных, который можно сойти с рук. Хранение ссылки на любой объект, который содержит открытые системные ресурсы (особенно соединение с базой данных) является определенным уничтожителем масштабируемости. Кроме того, хранить незафиксированные данные в переменной сеанса является просто плохой идеей в большинстве случаев. В целом это кажется, что текущая реализация оскорбительно использует объекты сессии попытаться моделировать приложение с сохранением информации в, предположительно, не сохраняющей состояния среде.
Хотя это очень порочат, модель ASP.NET руководящего состояния автоматически через скрытые поля должна действительно устранить большинство потребности сохранить что-либо в переменных сеанса.
Мое эмпирическое правило - то, что, чем более масштабируемый (с точки зрения пользователей/хитов), которым должно быть приложение, тем меньше можно сойти с рук использование состояния сеанса. Существует, однако, компромисс. Для веб-приложений, где пользователь неоднократно получает доступ к тем же данным и обычно имеет довольно долгую сессию на использование сайта, некоторое кэширование (при необходимости в объектах сессии) может на самом деле помочь масштабируемости путем сокращения нагрузки на сервер БД. Идея здесь состоит в том, что это намного более дешево и менее сложно для сельского хозяйства уровня представления, чем бэкенд DB. Конечно, со всеми вещами, этот совет должен быть воспринят умеренно и не применяется во всех ситуациях, но для довольно простого внутреннего Приложения типа CRUD, он должен служить Вам хорошо.
Очень похожий вопрос задали относительно сессий PHP ранее. В основном Сессии являются великолепным местом, чтобы хранить определенные для пользователя данные, к которым необходимо получить доступ через загрузки на несколько страниц. Сессии НЕ являются великолепным местом для хранения ссылок соединения с базой данных; Вы были бы лучше, чтобы использовать своего рода программное обеспечение организации пула подключений или открыться/закрыть Ваше соединение на каждой загрузке страницы. До кэширующихся данных на сессии это зависит от того, как данные сессии хранятся, в каком количестве безопасности Вы нуждаетесь, и характерны ли данные для пользователя. Лучшая ставка должна была бы использовать что-то еще для кэширования данных.
A: Данные, которые являются только относительно одного пользователя. IE: имя пользователя, идентификатор пользователя. Самое большее объект, представляющий пользователя. Иногда относительные URL данные (как то, где взять кого-то) или стопка сообщения об ошибке полезны для продвижения в сессию.
Если Вы хотите совместно использовать материал потенциально между различными пользователями, используйте хранилище Приложения или Кэш. Они намного выше.
Stephen,
Вы работаете на компанию, которая запускается с "I", который имеет веб-сайт, который запускается с "BC"? Это звучит точно как то, что я сделал, когда я сначала начал разрабатывать в .NET (и было молодо и глуп) - я переполнил все, о чем я мог думать на сессии и приложении. Само собой разумеется, это было двойным - плюс непольза.
В целом сторонитесь сессии как можно больше. Конечно, несериализуемые объекты не должны храниться там (соединения с базой данных и такой), но даже большие, сериализуемые объекты не должны быть также. Вы просто не хотите издержки.
Я всегда хранил бы очень мало информации на сессии. Сессии используют ресурсы памяти сервера, который является дорогим. Сохранение слишком многих значений на сессии увеличивает нагрузку на сервер, и в конечном счете функционирование сайта понизится. При использовании серверов баланса загрузки использование сессии может столкнуться с проблемами. Таким образом, то, что я делаю, использовать минимальный или никакие сессии, используйте cookie, если информация не является очень критической, используйте скрытые поля больше и сессии базы данных.