Реализация стейтмашины на Zend Framework3+Doctine2

[xztau]

стейтмашины

Конечного автомата?

[shadow00]

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

[shadow00]

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

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

Почему не рассматривал symfony/workflow — не знал о нем. Поинтересуюсь, спасибо. Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.

[shadow00]

С гарантиями в конфигурации или коде все проще: оно в приложении константно (для определенной версии) и гарантировано по определению.

Нельзя гарантировать, что упомянутое в конфигурации состояние будет в словаре состояний в БД. Для этого Вы и говорите об константах (если я Вас правильно понимаю), которые кто-то определил и сверил со словарем. Но зачем поддерживать 2 источника синхронными, если можно иметь один? Это же удобней.

[shadow00]

Не вижу причин в проекте со скелетом от одного фреймворка не использовать компоненты других, если вы это имели ввиду

Нет, в данном случае я просто подчеркнул, что это ПО тоже вполне хорошо себя зарекомендовало, не более того.

Против переиспользования компонентов в других фреймворках ничего не имею. Используем же мы доктрину например ;)

[shadow00]

VO. Он не соберется с кривого значения и вы получите ожидаемое исключение о кривой конфигурации
=====
Если Вы будете контролировать «кривые» значения при считывании конфигурации. БД уже это делает.

[shadow00]

ENUM вообще менять может быть довольно проблемно на больших таблицах.

согласен.

Сама таблица-словарь состояний в общем виде определяется двумя колонками: собственно идентификатор и какой-то алиас или тайтл. С приложения искать придется по этой второй колонке, и снова нет гарантии, что между приложением и БД не возникнет рассинхрон при очередном изменении кода или БД.

Идентификатор в статическом словаре делается строчным и смысл в алиасе тогда пропадает.
При динамическом словаре удобство хранения в БД по сравнению с файлом описал выше OnYourLips

[shadow00]

Иначе оно будет падать при попытке вставить какое-то другое.

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