Хранение данных в сеансе и заполнение при обратной передаче

Question

Что предпочтительнее: хранить набор данных в сеансе или заполнять набор данных при каждой обратной передаче?

Answer 1

Это будет зависеть от многих факторов. Обычно лучше не хранить слишком много элементов в памяти сеанса, если ваш сеанс находится в процессе или на сервере состояний, потому что он менее масштабируемый.

Если ваш сеанс находится в базе данных, может быть лучше просто запросить и повторно заполнить набор данных, если выполнение запроса не является дорогостоящим.

Answer 2

Не используйте сессию !!! Если пользователь откроет вторую вкладку с другим запросом, сеанс будет использован повторно, и результаты будут не такими, как он ожидает. Вы можете использовать комбинацию ViewState и Session, но все равно измеряете, сколько вы можете обработать без какого-либо кэширования, прежде чем прибегнуть к кэшированию.

Answer 3

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

Answer 4

Это зависит от того, насколько интенсивно вы будете это делать и где ваши данные сеанса хранятся на сервере.

Сохранение наборов данных в сеансе обязательно влияет на использование памяти . Все переменные сеанса хранятся в памяти или на сервере SQL, если вы используете состояние сервера SQL. Вы также можете разгрузить нагрузку на другой компьютер, используя режим State Server.

Сериализация / десериализация. Если вы используете безумно большие наборы данных, это может плохо повлиять на производительность сервера.

С другой стороны, наличие очень больших состояний просмотра на страницах может привести к снижению производительности . Поэтому я буду хранить наборы данных в сеансе или в кеше и искать «outproc» способ хранения данных этого сеанса.

Answer 5

Как уже отмечали другие ответы, ответ "зависит". Однако я предполагаю, что вы говорите о данных, которыми обмениваются пользователи. В этом случае вы должны , а не хранить набор данных в сеансе пользователя, но повторно заполнять при обратной передаче.

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

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

Answer 6

Ваш ответ не намекает на использование данных. Это справочные данные? Пользователь активно обновляет его? Предполагается, что более одного пользователя одновременно имеют доступ к обновлениям?

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

Обычно есть более эффективные способы управления большими наборами данных, не прибегая к загрузке всех данных в память.

В противном случае, если данные вашего приложения действительно чудовищны, рассмотрите мощный клиент с серверной частью веб-службы. Это может быть лучше, чем создание веб-страницы.

Answer 7

Я большой сторонник разделения и редко, если вообще когда-либо, вижу необходимость выбросить полный набор данных в пользовательский интерфейс.

На самом деле вы должны только передавать объекты в пользовательский интерфейс, который необходимо использовать, поэтому, если вы не показываете большую диаграмму или какую-то структуру данных, которая должна отображать отношения между данными, это не стоит затрат.

Меньшие подмножества данных, когда это применимо, гораздо эффективнее. Действительно ли ваше приложение использует все функции в наборе данных пользовательского интерфейса? если нет, то лучший способ продолжить - передать только те данные, которые вы отображаете.

Если вы привязываете данные к элементу управления, сортируете / разбиваете на страницы и т. Д. Через него, вы можете реализовать множество интерфейсов, позволяющих поддерживать этот набор данных, в виде гораздо меньшего куска кода.

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

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

ИМХО, наборы данных довольно плохо использовать, если вы беспокоитесь о производительности или использовании памяти.

Answer 8

проблема с сессией в том, что если она в процессе, она может исчезнуть, что не так уж и здорово, если это сервер состояний, то вам нужно сериализоваться, и если это sql sate, вы все равно совершаете обратный путь!

если набор результатов большой, выполните пользовательскую подкачку страниц, чтобы вы возвращали только небольшое подмножество общих результатов.

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

Если вы не хотите совершать многократные обходы и думаете, что у вас есть память, тогда поместите весь набор данных в кеш, но будьте осторожны, он не растает веб-сервер.

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

Что касается параллелизма при загрузке страницы вставки / редактирования, вам необходимо заполнить ее свежими данными и обновить кэш после добавления / обновления.

Answer 9

Я обычно держу его в сеансе, если он не слишком большой и / или дБ далеко и медленно. Если данные большие, в общем, лучше перезагрузить.

Иногда я использую Cache, загружаю из Db в первый раз и помещаю в кеш. Во время обратной проверки я проверяю chache и, если он пуст, я перезагружаю. Таким образом, сервер управляет кэшем самостоятельно.

Answer 10

Ни то, ни другое "не держите"! Отобразите только то, что нужно пользователю, и создайте эффективную схему подкачки, чтобы увидеть строки назад или вперед.

гр