Re[8]: Подходы к организации 3-tier
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 06.12.03 20:32
Оценка: 202 (19) +1
Здравствуйте, Igor Trofimov, Вы писали:

AVK>>О, это большой и сложный вопрос


iT>Менее интересно не стало


Да я понимаю Просто что то сейчас настроения нет на такие темы распространяться, отдыхаем-с от программирования.

Ты можешь и сам прикинуть где такое может быть. Основной недостаток стейтлесс модели — состояние приходится гонять по каналам передачи данных. Если размер такого состояния велик начинаются траблы.
Вот например длинные транзакции. Можно конечно долго говорить по поводу того что это зло, но к сожалению очень часто они необходимы именно исходя из бизнес-задачи. А длинная транзакция подразумевает хранение всех данных, которые в ней менялись. МС хитро предлагает скидывать эти данные в БД, но тут мы наблюдаем некую подмену понятий. Если мы скидываем данные в БД, то какой же это, к черту, стейтлес? Это самый натуральный стейтфул, только реализованый на основе стейтлес технологий коммуникации при помощи доставания гланд через неожиданное отверстие.

Стив Шварц, один из архитекторов СОМ+, а теперь наверное индиги, когда приезжал в Москву сказал примерно следующее:
никаких стейтлесов не существует в природе. Любой вариант это стейтфул. Вопрос только в одном — в длительности хранения этого самого состояния. Его то по возможности надо минимизировать. То есть в итоге двуполярный "стейтфул/стейтлес" заменяется на градиентное "длительность хранения состояний".

А дальше начинается самое интересное. Заученное "стейтлес всегда лучше масштабируется" оказывается не всегда верным! Нет, оно так если все данные под гребенку отнести либо к стейтлес, либо к стейтфул модели. Но мы же договорились что вводим градиентное разделение. А в свете этого мы видим старые и давно известные истины — оказывается данные не однородны. Есть данные меняющиеся крайне редко — например географические справочники. Есть данные средней изменяемости — справочники сотрудников и контрагентов (все это разумеется относительно, для каких то предприятий справочник контрагентов очень чатсо меняется, для каких то наоборот крайне редко, мы берем в среднем по больнице). И, наконец, есть данные, меняющиеся часто — заказы, отгрузки и т.д.

Ну с последними все ясно — обновляются они часто, посему избавляться от них надо быстрее. Собственно здесь показано то что что обычно обзывают стейтлес моделью. А вот с двумя другими категориями все несколько хитрее — совершенно понятно что для редко меняемых данных вся мощная логика поддержки блокировок/версий и изоляции в sql серверах работает по сути в холостую. А ведь в чистой стейтлес модели вся логика разруливания между клиентами ложится на sql сервер, который знать не знает и ведать не ведает о предметных свойствах хранимых данных. Вот и получается парадоксальная ситуация — на редко меняемых данных стейтлес модель оказывается хуже масштабируемой из-за неоптимальности и избыточности механики кеширования и блокировок.
В противоположность ей стейтфул модель на таких данных ведет себя хорошо, поскольку гибкое и обладающее большей информацией о предметной области ядро сервера приложений не вносит такого оверхеда. Редко меняющиеся данные спокойно можно постоянно держать в памяти , лишь изредка обращаясь к серверу БД, и не использовать на них практически никаких блокировок поскольку есть определенная гарантия что сильно эти данные не изменяться.
Как показывает практика — доля бизнес-сущностей, которые меняются часто невелика, хотя по объему они значительны. Это значит что мы можем написать только небольшую часть бизнес-кода в короткоживущем состоянии.
Есть еще одно преимущество стейтфул модели — программирование бизнес-логики в такой модели проще, поскольку не надо все стараться сделать за один чих со стороны клиента, обращение к состоянию не требует потокобезопасности.

Извини за философию, но что то меня сегодня на конкретику не тянет . Теперь осталось дождаться ответной философии от IT в защиту стейтлес модели и неделя будет завершена достойно целым философским трактатом
... << RSDN@Home 1.1.2 beta 1 (Win32NT 5.1.2600.0) >>
AVK Blog
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.