Здравствуйте, IT, Вы писали:

AVK>>Надо, но только параметры вызова, а не внутреннее состояние.

IT>Здесь мы дружно упираемся в вопрос, что эффективнее — забрать сразу всё состояние или выщемлять его из сервера по одному маленькому кусочку.

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

Ну и более простой к тебе вопрос из практики — как по твоему реализовать в веб-сервисе януса отсылку сообщений на сервер с гарантией отсутствия дублирования придерживаясь чистой стейтлес модели?

AVK>>А зачем делать два вызова одного и того же?

IT>Ну как же? Твой объект живёт на сервере и у меня имеется только ссылка на него. Занимать такой ерундой как запоминать какие его свойства я уже прочитал, а какие нет, я не собираюсь.

У меня другой подход. Клиента в большинстве случаев можно написать универсального и какие то сложности с его оптимизацией меня не волнуют, это нужно будет сделать один раз. А вот бизнес-код переписывается каждый раз по новой. Отсюда лично мой критерий оптимизации — упрощение бизнес-кода и вынесение из него всей специфики среды выполнения максимальным образом. Исходя из этого стейтлес модель не всегда лучший выбор, поскольку тяжесть управления состояниями и откатом перекладывает на бизнес-код.

AVK>>Как я ниже писал — стейтфул модель себя оправдывает на редко изменяющихся данных, а для них такое просто бессмысленно.

IT>Т.е. ты всё же клонируешь объект?

В бизнес-коде нет, на клиента во многих случаях да.

IT>Но если же заниматься разработкой такого софта, при этом работая в отделе автоматизации, то гуд лак

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

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

IT>С ними всегда бяка.

Тем не менее в стейтфул модели бяка поменьше.

IT>Но тем не менее наиболее эффективными решениями, как это ни странно, оказыватеся реализация таких алгоритмов как батч процесс непосредственно в самом SQL сервере (если это, конечно, возможно).

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

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

IT>Мы же говорим не о stateful vs sql. Stateless же о предметной области осведомлён не чуть не хуже stateful.

Разумеется. Только у стейтлес эту осведомленность проявить куда меньше возможностей. Сам же призаешь что в стейтлес модели основная тяжесть разруливания состояний ложится на sql сервер. С одной стороны это очень хорошо, особенно в малобюджетных проектах. Но с другой стороны это же ограничивает простор для оптимизации на основе метаданных бизнес-логики. Как всегда надо выбирать золотую середину.

IT>Чудес не бывает. Снимая нагрузку с сервера БД ты её просто переносишь на сервер приложений, вот и всё.

Безусловно.

IT>Насчёт более оптимальных запросов, обеспечиваемых сервером приложений. Это справедливо только для примитивных запросов, и то же самое можно закешировать и в stateless. Для сложных запросов на практике это не реально. Пять строчек на SQL с парой вложенных джоинов обычно выливаются в десятки, если не в сотни строк на C++/C#/whatever, реализующих поиск, фильтрацию и сортировку в объектной модели и отнюдь не отличаются быстродействием доморощенных алгоритмов.

Ты не про ту оптимизацию речь ведешь. Оптимизируются не запросы, оптимизируется взаимодействие состояний. Пытаться оптимизировать голые данные вместо sql сервера бесполезно и даже вредно. Оптимизировать нужно то что sql сервер оптимизировать в принципе не в состоянии.

AVK>>Может и ерунда но именно так оно выходит на реальных серверах.

IT>На разных реальных серверах обычно всё по разному.

Разумеется. Потому я особо оговорился — речь идет об управлении предприятием. Т.е. наш сайт под это уже не попадает.

IT>Я пока что-то не пойму, откуда такая уверенность что в stateless над БД так и наровят постоянно надругаться.

Потому что больше некому. Необходимость постоянно скидывать в него состояния увеличивает суммарную на него нагрузку и размазывает ее по времени.

IT> Да, действительно, в stateless БД является центральным звеном, но все усилия сервера как раз и направлены на снятие нагрузки с сервера базы данных.

Хороши усилия — после каждого запроса скидывать состояние в БД

IT>Насчёт сайта ты прав, на счёт остального сомневаюсь. Я вам, конечно, не скажу за всю Россию , давно там не был, и за всю Америку тоже не скажу, но не думаю, что задачи и там и здесь очень уж сильно отличаются.

Зря.

IT> Что там управление предприятиями, что тут,

Разница в размерах предприятий и количестве изменений законов и порядков начислений в единицу времени.

IT>что там лоскутная автоматизация никого не устраивает, что здесь. Тем не менее все латали, латают и будут латать.

В России чаще всего и латать то нечего. Либо автоматизации нет совсем, либо она на примитивном уровне самопальных однопользовательских программулек. Лет через 15-20 у нас наверное и законы устаканяться и на каждом предприятии будут легаси-системы, но это все нескоро.

IT>Слова мужа Вопрос только в том, какую модель брать в качестве базовой, от чего отталкиваться.

Слова Стива Шварца помнишь?

AVK>>Веб-приложения как правило никто и не стремится сделать стейтфул.

IT>Да уже и GUI не очень-то стремяться. Более того, оказывается в GUI очень неплохо смотрятся несложные веб-формы

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

AVK>>Масштабирование тяжелых задач вобще очень сложная задачка вне зависчимости от модели и тот же Стив Шварц приводил очень причудливые схемы масштабирования, никак не привязанные к какой то поределенной модели.

IT>Возможно. Насочинять можно много чего.

Ну он вроде как говорил где именно та или иная схемка реализована на практике.

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

IT>Самое фиговое в stateful — это когда понимаешь что чтобы сделать следующий шаг, нужно пройти в два раза больше чем пройдено, что столько усилий потрачено, а результат получился хреновый.

Это уже недостаток не модели, а архитектуры. И там и там можно напороться на такое по полной программе. Кроме того не следует пытаться надуть муху до размеров слона. Если начинали с решения для малых предприятий пытаться потом получить из этого кластерного монстра неразумно.

AVK>>А приложения, одинаково хорошо подходящие под любую нагрузку это миф. Нет таких в природе. Вот одинаково плохо есть.

IT>Вопрос не в конкретном приложении. Вопрос в том какая архитектура позволит это приложение расширять с минимальными усилиями.

Нет приложений, которые можно расширять с минимальными усилиями до бесконечности. В любую архитектуру изначально закладываются границы применимости. Если очень хочется потом за эти границы шагнуть то нужно проводить глубокий рефакторинг. Так вот — увеличить масштабируемость кода можно кучей разных способов — можно придерживаться стейтлес модели и городить кластеры, можно максимально изолировать бизнес-логику от специфики ядра и источника данных. Стейтфул модель ведь не отменяет кластеризации sql-сервера.