Комментарии
14
стейтмашины
Конечного автомата?
да конечно. Просто почему-то в моем окружении обычно используют англоязычное заимствование.
Почему не рассматривали подключение готового и прекрасно работающего symfony/workflow пакета?
Описание графа переходов мы будем хранить в таблице базы данных потому чтоПричины так-себе, особенно про наглядность. Думаю, что гораздо правильнее было бы хранить это в конфигурации, за исключением случаев, когда настройка самого workflow — это часть интерфейса пользователя (как в Jira).
Не соглашусь на счет правильности хранения в конфигурации. Один из аргументов Вы сами высказали — возможность модификации через интерфейс.
И хранение в БД гарантирует использование того же словаря состояний в переходах, что и в ентити объекта с помощью внешних ключей. А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле?
Мне пришлось работать с конечным автоматом с конфигурацией в хмл. Даже при небольшом количестве переходов листать длинный конфиг неудобно, там много лишнего на мой взгляд было описано.
Почему не рассматривал symfony/workflow — не знал о нем. Поинтересуюсь, спасибо. Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.
И хранение в БД гарантирует использование того же словаря состояний в переходах, что и в ентити объекта с помощью внешних ключей. А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле?
Мне пришлось работать с конечным автоматом с конфигурацией в хмл. Даже при небольшом количестве переходов листать длинный конфиг неудобно, там много лишнего на мой взгляд было описано.
Почему не рассматривал symfony/workflow — не знал о нем. Поинтересуюсь, спасибо. Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.
Один из аргументов Вы сами высказали — возможность модификации через интерфейс.Это единственный аргумент, и он нужен только в ПО, где это ключевой функционал, это лишь совсем небольшая часть случаев.
И хранение в БД гарантирует использование того же словаря состояний в переходах, что и в ентити объекта с помощью внешних ключей. А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле?С гарантиями в конфигурации или коде все проще: оно в приложении константно (для определенной версии) и гарантировано по определению.
Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.Не вижу причин в проекте со скелетом от одного фреймворка не использовать компоненты других, если вы это имели ввиду. PSR для этого и появились.
зы. даже файловые конфиги можно править из интерфейса
oxidmod вынужден не согласиться про файловые конфиги, которые можно править из интерфейса. В этом случае конфиги перестают быть частью приложения и становятся данными. И нет принципиальной разницы, где их хранить: в файловом хранилище ли в реляционной СУБД. Вот только второй вариант из этих двух удобнее.
С гарантиями в конфигурации или коде все проще: оно в приложении константно (для определенной версии) и гарантировано по определению.
Нельзя гарантировать, что упомянутое в конфигурации состояние будет в словаре состояний в БД. Для этого Вы и говорите об константах (если я Вас правильно понимаю), которые кто-то определил и сверил со словарем. Но зачем поддерживать 2 источника синхронными, если можно иметь один? Это же удобней.
Не вижу причин в проекте со скелетом от одного фреймворка не использовать компоненты других, если вы это имели ввиду
Нет, в данном случае я просто подчеркнул, что это ПО тоже вполне хорошо себя зарекомендовало, не более того.
Против переиспользования компонентов в других фреймворках ничего не имею. Используем же мы доктрину например ;)
вынужден не согласиться про файловые конфиги
Это было лишь примечание, что и их можно править, если сильно нужно.
А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле
VO. Он не соберется с кривого значения и вы получите ожидаемое исключение о кривой конфигурации
зы. даже файловые конфиги можно править из интерфейса
VO. Он не соберется с кривого значения и вы получите ожидаемое исключение о кривой конфигурации
=====
Если Вы будете контролировать «кривые» значения при считывании конфигурации. БД уже это делает.
=====
Если Вы будете контролировать «кривые» значения при считывании конфигурации. БД уже это делает.
Все не так просто с БД. Есть 2 более-менее нормальных варианта поддержания целостности для «состояния».
Первый — это ENUM. У нас есть перечисление возможных состояний и нельзя вставить в бд кривое значение. ENUM нельзя редактировать с интерфейса. ENUM вообще менять может быть довольно проблемно на больших таблицах.
Второй — отдельная таблица-словарь состояний. В основной таблице идентификатор и внешний ключ. Можно редактировать с интерфейса, но не очень удобно работать с приложения. Теперь, чтобы приложение могло добавить новую запись с определенным состоянием, нужно сначала с БД получить идентификатор этого состояния. Сама таблица-словарь состояний в общем виде определяется двумя колонками: собственно идентификатор и какой-то алиас или тайтл. С приложения искать придется по этой второй колонке, и снова нет гарантии, что между приложением и БД не возникнет рассинхрон при очередном изменении кода или БД.
В последнее время я начал использовать VO для таких вещей. В БД просто примитив (чаще всего SMALLINT), без ограничений и ключей, но при гидрации в объект, мы получим эксепшен о кривом значении. Пока мне кажется, что этот подход самый гибкий и простой в реализации. Любые изменения в бизнес логике состояний требуют лишь правок кода, но не изменения схемы.
Первый — это ENUM. У нас есть перечисление возможных состояний и нельзя вставить в бд кривое значение. ENUM нельзя редактировать с интерфейса. ENUM вообще менять может быть довольно проблемно на больших таблицах.
Второй — отдельная таблица-словарь состояний. В основной таблице идентификатор и внешний ключ. Можно редактировать с интерфейса, но не очень удобно работать с приложения. Теперь, чтобы приложение могло добавить новую запись с определенным состоянием, нужно сначала с БД получить идентификатор этого состояния. Сама таблица-словарь состояний в общем виде определяется двумя колонками: собственно идентификатор и какой-то алиас или тайтл. С приложения искать придется по этой второй колонке, и снова нет гарантии, что между приложением и БД не возникнет рассинхрон при очередном изменении кода или БД.
В последнее время я начал использовать VO для таких вещей. В БД просто примитив (чаще всего SMALLINT), без ограничений и ключей, но при гидрации в объект, мы получим эксепшен о кривом значении. Пока мне кажется, что этот подход самый гибкий и простой в реализации. Любые изменения в бизнес логике состояний требуют лишь правок кода, но не изменения схемы.
ENUM вообще менять может быть довольно проблемно на больших таблицах.
согласен.
Сама таблица-словарь состояний в общем виде определяется двумя колонками: собственно идентификатор и какой-то алиас или тайтл. С приложения искать придется по этой второй колонке, и снова нет гарантии, что между приложением и БД не возникнет рассинхрон при очередном изменении кода или БД.
Идентификатор в статическом словаре делается строчным и смысл в алиасе тогда пропадает.
При динамическом словаре удобство хранения в БД по сравнению с файлом описал выше OnYourLips
Даже если это одна строчная колонка, приложение фактически должно знать, какое это значение. Иначе оно будет падать при попытке вставить какое-то другое. У вас все равно есть необходимость держать копию этого словаря в приложении.
По большому счету какая разница, ошибка вылетит с уровня бд о нарушении констрейнта или с самого приложения, о невозможности собрать VO.
Более того, вы экономите один запрос в бд и упадете до его выполнения.
По большому счету какая разница, ошибка вылетит с уровня бд о нарушении констрейнта или с самого приложения, о невозможности собрать VO.
Более того, вы экономите один запрос в бд и упадете до его выполнения.
Иначе оно будет падать при попытке вставить какое-то другое.
Вам все равно прийдется это отслеживать, потому что действие может передаваться параметром запроса в ряде приложений.
Стейтмашина просто сгенерирует в этом случае исключение, которое должно быть перехвачено выше по стеку и обработано.
А поскольку все равно будет такая обработка, то после этого использовать константы в коде или использовать фактически те же константы из БД значения особого имееть не будет.
Если в приложении не предусмотрена передача действия как параметра, тогда Вы вольны добавить константы. Этой возможности никто не отнимает. Если передается, то смысл исчезает.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Реализация стейтмашины на Zend Framework3+Doctine2