Сколько данных может/должно, Вы храните в пользовательском объекте сессии?
Многие объяснения уже присутствуют, чтобы объяснить, как это происходит и как это исправить, но вы также должны следовать рекомендациям, чтобы избежать NullPointerException вообще.
См. также: A хороший список лучших практик
Я бы добавил, очень важно, хорошо использовать модификатор final. Использование "окончательной" модификатор, когда это применимо в Java
Сводка:
- Используйте модификатор
finalдля обеспечения хорошей инициализации. - Избегайте возврата null в методы, например, при возврате пустых коллекций.
- Использовать аннотации
@NotNullи@Nullable - Быстрое завершение работы и использование утверждений, чтобы избежать распространения нулевых объектов через все приложение, когда они не должен быть пустым.
- Сначала используйте значения с известным объектом:
if("knownObject".equals(unknownObject) - Предпочитают
valueOf()поверх toString (). - Используйте null safe
StringUtilsStringUtils.isEmpty(null).
5 ответов
Принятие информации не чувствительно затем, Вы могли хранить информацию в cookie, который уменьшит объем информации, требуемый быть сохраненной стороной сервера. Это также позволило бы Вам получать доступ к информации через JavaScript.
Кроме того, Вы могли использовать состояние отображения, чтобы хранить информацию, хотя это может привести к большому объему данных, отправляемых между сервером и клиентом и не моим предпочтительным решением.
Объем информации сессии, которую необходимо хранить, варьируется дико в зависимости от приложения, числа ожидаемых пользователей, спецификация сервера и т.д. Дать более точный ответ запросило бы больше информации :)
Наконец, предполагая, что информация, собранная в течение процесса, не запрашивается от страницы до страницы затем, Вы могли хранить всю информацию в таблице базы данных и только сохранить уникальный идентификатор записей на сессии. Поскольку каждая страница отправлена, запись дб обновляется, и затем на заключительной странице вся информация получена и отправлена. Это не решение для идеи, если необходимо получить предыдущую информацию на каждой последующей странице из-за количества требуемых чтений дб.
Вы могли также иметь 1 страницу ASP со всей формой HTML, и скрыть части ее до пользовательской заливки и "отправляете" видимую часть...
затем просто скройте часть, которая заполнена, и покажите следующую часть формы...
Это было бы чрезвычайно легко в платформе.NET, использовать панели для каждого "шага мастера" и добавить логику, когда отобразить и скрыть каждую панель.
у Вас затем будут все данные на одной странице.
Если Вы используете традиционную модель HTTP (т.е. не используйте runat = "сервер"), можно отправить данные на другую страницу ASP и поместить отправленные данные в скрытые элементы формы, можно сделать это для однако многих страниц, Вам нужно таким образом предотвращение, помещающее что-либо в переменную сеанса.
Так как это проблематично с точки зрения производительности для хранения больших объемов данных в объекте сеанса пользователя, ASP.NET обеспечивает некоторые другие обходные решения сверху того, что упоминается в сообщениях выше. Поставщик Профиля ASP.NET позволяет Вам сохранять сопутствующую информацию сессии в базе данных. Можно также использовать Сервер Состояния сеанса, который использует отдельный сервер, чтобы хранить всю информацию Сессии. Обе из этих ситуаций принимают во внимание, необходимо ли использовать кластеры или подсистемы балансировки нагрузки, серверы могут все еще распознать информацию о сессии через различные серверы. Если Вы храните информацию в объекте Сеанса HTTP, Вы сталкиваетесь с проблемой, что один пользователь должен всегда переходить к тому же серверу для той сессии.
Сессия, состояние просмотра, база данных. Все они медленные, но выполнят свою работу.
Скрытые поля формы - это ответ, который мне нравится больше всего.
Есть и другие способы сохранить состояние. Файлы cookie, всплывающее окно, набор фреймов или окна iframe.