Здравствуйте, Hacker_Delphi, Вы писали:
H_D>Более того, я сделаю более сильное утверждение, чем сделаное чуть выше:
H_D>действительно интерактивную систему принятия решений на основе актуальных данных НЕВОЗМОЖНО сделать в рамках модели стейтлесс.
Да, действительно, сильное утверждение
Только хотелось бы услышать более чёткое определение понятия "действительно". "Очень действительно" или "совсем действительно" не предлагать
H_D>На предстоящий вопрос почему сразу отвечу в виде леммы:
Вот до чего может довести хорошего человека излишнее увлечение глупыми книжками
H_D>Утверждение 1. Отадвать бизнес логику на клиент — неверно, так как всегда можно залезть "внутрь" объекта и что-то поправить/нарушить/подсмотреть.
Что значит залезть внутрь? Речь о хаках или о преднамеренном обходе программистом ограничений модели?
H_D>Утверждение 2. Из (1) следует, что вся бизнес логика живет на сервере и никакая ее часть не может жить на клиенте.
Первичная валидация данных, например. Зачем гонять на сервер строчку "bla-bla-bla", если известно, что она должна содержать маску ###-###-####?
H_D>То есть в случае, если верно (3) — стейтлесс получается не ООП, а процедурным программированием, что откатывает нас назад в развитии программирования, так как почти ничем не отличается от RDBMS 
Я же говорю книжек начитался
В таком случае позволю себе крамольную цитату, всего один абзац:
...
Because the contract and schema for a given service are visible over broad ranges of both space and time, service-orientation requires that contracts and schema remain stable over time. In the general case, it is impossible to propagate changes in schema and/or contract to all parties who have ever encountered a service. For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code.
...
Code Name Indigo <br />
A Guide to Developing and Running Connected Systems with Indigo
Don Box
Это лишь одно из мест где Дон Бокс пока осторожно упоминает, что на ООП мир клином не сошёлся. Тем не менее основаная мысль вполне ясна — share schema and contracts, not class. Под это в основном и заточен Indigo.
Так что
Кто там год назад с упорством защищал C++? Пришла пора встать на защиту ООП! Вперёд!
H_D>Вывод 1. из (4) Режим с стейтлесс и использованием Serializable объектов, отдаваемых на сторону клиента не является работой ООП, так как гонять что-либо сложнее структур нет никакого смысла — все равно все, что выполняется на клиенте требует копии кода на клиенте, а все, что выполняется на сервер требует вызовов сервера в стиле процедурного программирования, а не ООП.
Хана твоему ООП. Сегодня рулят схемы и контракты
H_D>Вывод 2. Из (7) и (9), через (8) мы получаем, что создание интерактивных систем со всегда актуальными данными на базе стейтлесс с использованием MBR невозможно.
В общем ход твоих мыслей я уже давно потерял, но мимо этого пройти не могу, религия не позволяет
Ты в своём доказательстве забыл одну простую вещь. Для реализации подобного механизма в stateful необходимо как минимум поддерживать версию объекта, которая является частью состояния. Но ведь в stateless состояние не куда не девается, просто оно в другом месте. Если учесть что многие разработчики используют в различных целях поля типа LastModifiedDateTime, то такой атрибут версионности у нас уже часто есть. Если нет, то его не лишним будет добавить наряду с LastModifiedUserID. В таком случае, то о чём ты говоришь реализуется элементарно с помощью следующего запроса:
UPDATE
Whatever
SET
...,
LastModifiedDateTime = getdate()
WHERE
... AND
LastModifiedDateTime = @LastModifiedDateTime
Далее либо прямо в SQL сервере, либо в бизнеслогике достаточно проверить число сохранённых записей и если оно равно 0, то кидаем исключение. В результате имеем — кто первый встал того и тапки. При этом, заметь, практически никакого оверхеда.
H_D>Следствие 4. из (11) мы получаем проблему. Если 10 человек взяли себе для просмотра объект и каждый решил его изменять (причем, с точки зрения сервера все это одновременно) — мы получим либо классическую проблему неадекватности данных "версионников" (кто последний — тот и прав), либо нам нужно делать блокировки, что подразумевает стейтфул модель данных, так как в стейтлесс блокировки невозможны, либо оповещать остальных клиентов об изменении данных и необходимости их обновить, что также требует хранения на сервере ВСЕХ контекстов ВСЕХ клиентов, что противоречит модели стейтлес.
Видишь, оказывается всё совсем не так. Эта проблема легко решается. Кстати, если не устраивает дата, то можно зарядить и обычный int.
H_D>Вывод 4. Даже при использовании Serializable объектов, интерактивная система невозможна на основе стейтлес модели.
H_D>Вывод 5. Из Выводов 1(5), 2(10) и 3 (13) мы видим, что построение интерактивных приложений, отображающих всегда актуальные данные, невозможно при использовании стейтлесс.
На будущее, мой тебе совет. Никогда не делай категорических выводов
H_D>Итак, окончательный вывод: невозможно построение систем интерактивного принятия решений на основе только стейтлес модели.
Ну всё, хватит меня смешить
H_D>стейтлес модель хороша только тогда, когда нам нужно выполнять резервирование/продажи, причем всякое действие не требует никакой интерактивности — то есть :
Это обсуждение мы давай лучше отложим. Я лишь намекну, что на stateless сделать можно всё, т.к. название эта модель получила не из-за того, что состояния в ней нет, а из-за того, что серверные объекты бизнес логики ака сервисы в терминах Дон Бокса, манипулируя этими состояниями, в себе самих их не хранят. Объекты же, которые можно рассматривать как аналоги полноценных объектов в stateful, пролетают через апп-сервер со свистом в обоих направлениях и долго там не задерживаются. Состояние же никуда не девается, и следовательно никаких особенных недостатков по сравнению со stateful нет. Есть только преимущества
Если нам не помогут, то мы тоже никого не пощадим.
