В каком сценарии состояние с сохранением состояния лучше, чем без сохранения состояния для сети?

Question

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

Есть ли у вас ситуации, в которых состояние с состоянием более уместно, чем без гражданства?

Answer 1

Наш проект использует веб-фреймворк Wicket, который позволяет взаимодействовать с состоянием или без сохранения состояния. Страницы с состоянием имеют ряд преимуществ:

• Использование страницы с сохранением состояния в калитке упрощает частичное обновление страницы с помощью AJAX-среды wicket
• Stateful - более «интуитивная» модель программирования,Например, в классе страницы калитки я могу объявить поле приватного члена на стороне сервера, установить его при загрузке страницы и снова обращаться к нему каждый раз, когда запрос AJAX попадает на страницу для выполнения какого-либо обновления.
• Wicket предотвращает большинство распространенных проблем параллелизма на веб-уровне, синхронизируя объект пользовательского сеанса при обработке запроса.
• Сохранение состояния на стороне сервера может иногда повысить производительность;например, объект, который требует много времени для создания, но должен быть доступен странице, может быть загружен только один раз, когда страница впервые создается.

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

Ссылка на калитку: http://wicket.apache.org/

Answer 2

Использование состояний, как правило, облегчает работу программиста.

Однако состояния также создают всевозможные проблемы параллелизма, которые просто не возникают в ситуациях без состояния.

По сути, это спор между функциональнымии императивное программирование.

Answer 3

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

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

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

Лучшим подходом является сохранение сеанса за веб-серверами в каком-либо хранилище данных, в наши дни для этого доступно множество отличных продуктов nosql (redis, mongo ,asticsearch, memcached). Таким образом, веб-серверы не сохраняют состояние, но у вас все еще есть состояние на стороне сервера, и доступностью этого состояния можно управлять, выбрав правильную настройку хранилища данных. Эти хранилища данных обычно имеют большую избыточность, поэтому почти всегда должна быть возможность вносить изменения в ваше веб-приложение и даже в хранилище данных без влияния на пользователей.

Answer 4

Из-за масштабируемости я нахожусь в состоянии полного состояния клиентского сервера без состояния, но когда сталкиваюсь с трудностями объяснения того, почему то и другое стало сложнее реализовать с помощью сервера без состояния, в долгосрочной перспективе вы как бы подали в отставку, вот гдесервер с состоянием светит :). Несмотря на то, что я предпочитаю statefull клиент, это нелегко реализовать эффективно с использованием asp.net viewstate, и, возможно, именно здесь Statefull Web становится практичным. Я думаю, что клиент Statefull, сервер без сохранения состояния, позволяет лучше понять объем данных, передаваемых между шинами. Иногда это скрыто, пока не возникнет проблема с использованием модели программирования сервера Statefull. Кроме того, легко перейти от состояния без состояния к состоянию (просто игнорируйте информацию о состоянии, которую вы предоставляете, поскольку вы уже знаете это ..). Идти в обратном направлении практически невозможно / не стоит. Другая вещь, использующая сервер Statefull, заключается в том, что очистка состояния / кэша часто является проблемой, когда вы используете также клиент Statefull. Это просто не интуитивно понятно и сбивает с толку, или, может быть, я просто недоволен :)

Во всяком случае, GWT и многие другие современные инструментарии (Silverlight разговаривают с WCF) предпочитают клиент с состоянием, сервер без сохранения состояния из-за проблем с масштабируемостью. Возможно, сервер с состоянием должен быть исключением из правила без состояния ... можно выбрать для каждой страницы / окна.

источники: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/2871ef5076c1bdb6/43e7a5377047aa44?#43e7a5377047aa44

Answer 5

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