Без сохранения состояния или с сохранением состояния

Меня интересуют статьи, в которых есть конкретная информация о дизайне без сохранения состояния и с сохранением состояния в программировании. Мне интересно, потому что я хочу узнать об этом больше, но я действительно не могу найти никаких хороших статей об этом. Я прочитал десятки статей в Интернете, в которых неопределенно обсуждается эта тема, или в них говорится о веб-серверах и сеансах, которые также являются `` с сохранением состояния или без состояния '', но меня интересует дизайн атрибутов без состояния и с отслеживанием состояния при кодировании . Пример: я слышал, что BL-классы не имеют состояния по своей конструкции, классы сущностей (или, по крайней мере, так я их называю - например, Person (id, name, ..)) имеют состояние и т. Д.

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

В любом случае, очень коротко, вот что я знаю о сохранении состояния и без сохранения состояния:

С отслеживанием состояния (например, WinForms): хранит данные для дальнейшего использования, но ограничивает масштабируемость приложения, поскольку оно ограничено ограничениями ЦП или памяти.

Без сохранения состояния (как ASP.NET - хотя ASP пытается поддерживать состояние с помощью ViewStates): после завершения действий данные передаются, а экземпляр возвращается в пул потоков (аморфный).

Как видите, это довольно расплывчатая и ограниченная информация (и в основном сосредоточена на взаимодействии с сервером), поэтому я был бы очень благодарен, если бы вы могли предоставить мне более вкусную информацию :)

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

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

Еще одна область, которую вы могли бы изучить, чтобы лучше понять, - это веб-службы RESTful. Они по своей природе «не имеют состояния», в отличие от других веб-технологий, которые пытаются каким-то образом сохранять состояние. (На самом деле то, что вы говорите, что ASP.NET не имеет состояния, неверно - ASP.NET изо всех сил пытается сохранить состояние с помощью ViewState и определенно следует характеризовать как сохраняющий состояние. С другой стороны, ASP.NET MVC - это технология без сохранения состояния). Есть много мест, где обсуждается «безгражданство» веб-сервисов RESTful (например, это место в блоге), но вы можете снова начать с вопроса SO .

Без гражданства означает, что нет памяти о прошлом. Каждая транзакция выполняется так, как если бы она была сделана впервые.

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

Без гражданства:

// The state is derived by what is passed into the function

function int addOne(int number)
{
    return number + 1;
}

Состояние:

// The state is maintained by the function

private int _number = 0; //initially zero

function int addOne()
{
   _number++;
   return _number;
}

Обратитесь по ссылке : /software/101337/whats-the-difference-between-stateful-and-stateless

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

Приложения без сохранения состояния не раскрывают никакой этой информации. Они каждый раз дают один и тот же ответ на один и тот же запрос, вызов функции или метода. HTTP не имеет состояния в необработанном виде - если вы выполняете GET для определенного URL-адреса, вы получаете (теоретически) один и тот же ответ каждый раз. Исключением, конечно же, является ситуация, когда мы начинаем добавлять отслеживание состояния поверх, например, с веб-приложениями ASP.NET :) Но если вы думаете о статическом веб-сайте только с HTML-файлами и изображениями, вы поймете, о чем я.

Прилагательное Stateful или Stateless относится только к состоянию диалога, а не в связи с концепцией функции, которая обеспечивает одинаковый вывод для одного и того же ввода. В таком случае любое динамическое веб-приложение (с базой данных за ним) будет сервисом с отслеживанием состояния, что, очевидно, неверно. Имея это в виду, если я поручаю задачу поддерживать состояние разговора в базовой технологии (например, в сеансе coockie или http), я реализую службу с отслеживанием состояния, но если вся необходимая информация (контекст) передается как параметры, I ' м реализация услуги без сохранения состояния. Следует отметить, что даже если переданный параметр является «идентификатором» диалогового состояния (например, билет или sessionId), мы все еще работаем в службе без отслеживания состояния,

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

Просто чтобы добавить чужой вклад .... Другой способ - взглянуть на это с точки зрения веб-сервера и параллелизма ...

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

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

Мы делаем Webapps полноценными, переопределяя поведение HTTP без сохранения состояния с помощью объектов сеанса. Когда мы используем объекты сеанса, состояние переносится, но мы по-прежнему используем только HTTP.

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

• Классы сущностей должны иметь состояние
• Классы помощников / рабочих не должны иметь состояния.