Комментарии 14
да конечно. Просто почему-то в моем окружении обычно используют англоязычное заимствование.
Почему не рассматривали подключение готового и прекрасно работающего symfony/workflow пакета?

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

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

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

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

Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.
Не вижу причин в проекте со скелетом от одного фреймворка не использовать компоненты других, если вы это имели ввиду. PSR для этого и появились.

зы. даже файловые конфиги можно править из интерфейса

oxidmod вынужден не согласиться про файловые конфиги, которые можно править из интерфейса. В этом случае конфиги перестают быть частью приложения и становятся данными. И нет принципиальной разницы, где их хранить: в файловом хранилище ли в реляционной СУБД. Вот только второй вариант из этих двух удобнее.
С гарантиями в конфигурации или коде все проще: оно в приложении константно (для определенной версии) и гарантировано по определению.

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

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

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

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

вынужден не согласиться про файловые конфиги


Это было лишь примечание, что и их можно править, если сильно нужно.
А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле


VO. Он не соберется с кривого значения и вы получите ожидаемое исключение о кривой конфигурации

зы. даже файловые конфиги можно править из интерфейса
VO. Он не соберется с кривого значения и вы получите ожидаемое исключение о кривой конфигурации
=====
Если Вы будете контролировать «кривые» значения при считывании конфигурации. БД уже это делает.
Все не так просто с БД. Есть 2 более-менее нормальных варианта поддержания целостности для «состояния».
Первый — это ENUM. У нас есть перечисление возможных состояний и нельзя вставить в бд кривое значение. ENUM нельзя редактировать с интерфейса. ENUM вообще менять может быть довольно проблемно на больших таблицах.
Второй — отдельная таблица-словарь состояний. В основной таблице идентификатор и внешний ключ. Можно редактировать с интерфейса, но не очень удобно работать с приложения. Теперь, чтобы приложение могло добавить новую запись с определенным состоянием, нужно сначала с БД получить идентификатор этого состояния. Сама таблица-словарь состояний в общем виде определяется двумя колонками: собственно идентификатор и какой-то алиас или тайтл. С приложения искать придется по этой второй колонке, и снова нет гарантии, что между приложением и БД не возникнет рассинхрон при очередном изменении кода или БД.

В последнее время я начал использовать VO для таких вещей. В БД просто примитив (чаще всего SMALLINT), без ограничений и ключей, но при гидрации в объект, мы получим эксепшен о кривом значении. Пока мне кажется, что этот подход самый гибкий и простой в реализации. Любые изменения в бизнес логике состояний требуют лишь правок кода, но не изменения схемы.
ENUM вообще менять может быть довольно проблемно на больших таблицах.

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

Идентификатор в статическом словаре делается строчным и смысл в алиасе тогда пропадает.
При динамическом словаре удобство хранения в БД по сравнению с файлом описал выше OnYourLips
Даже если это одна строчная колонка, приложение фактически должно знать, какое это значение. Иначе оно будет падать при попытке вставить какое-то другое. У вас все равно есть необходимость держать копию этого словаря в приложении.
По большому счету какая разница, ошибка вылетит с уровня бд о нарушении констрейнта или с самого приложения, о невозможности собрать VO.
Более того, вы экономите один запрос в бд и упадете до его выполнения.
Иначе оно будет падать при попытке вставить какое-то другое.

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