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

хъ

AVK>Ты спросишь — а при чем здесь стейтфул. В простейшем случае действительно не при чем. Но дальше приходит заказчик и говорит что из формы основного документа он хочет редактировать подчиненные. И при этом если основной документ потом будет откачен нужно откатить и все подчиненные. И вот тут то со стейтлес моделью все становится не очень шоколадно.

Не вижу проблем (если база верно спроектирована). У меня как раз такая ситуация и я прекрасно обхожусь стейтлесс моделью.

хъ

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

Дык это стейтфул управляет всей тяжестью состояний, а не стейтлес! О потом, я вот уже много раз слышал про тяжесть отката, но никак не могу понять, в чем она выражается?

хъ

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

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

Блин! Ты хочешь сказать, что в стейтфул модели проблемы перекладываються на машину и она код лабает? Что ты подрузомеваешь под проблемами? Реализация бизнес-логики всегда лежит на программере, а вот реализация правил ссылочной целостности — нет.

хъ

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

А можно по подробнее на счет этой оптимизации. Оптимизацию SQL сервера я знаю, оптимизацию софта тоже, но оптимизацию логики на основе метаданных...

хъ

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

А именно?

хъ

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

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

хъ

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

Не обязательно. Кеш еще никто не отменял.

хъ

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

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

С помощью железа можно расшарять до бесконечности.

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

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