#ruby-on-rails #ruby-on-rails-3
#ruby-on-rails #ruby-on-rails-3
Вопрос:
Я разрабатываю приложение для управления проектами для внутреннего использования. Для хранения требований проекта в настоящее время я планирую реализовать наследование одной таблицы, например:
Вывод < Требование
Проект < Требование
Мой вопрос в том, будет ли конечный автомат лучше в этом сценарии вместо STI. Чтобы требование проекта могло переходить из одного состояния в другое, например:
Руководство -> Проект -> Отменено
Руководство -> Проект -> Завершено
и т.д…
Я не уверен, хорошо ли я разбираюсь в конечных автоматах, и если мой вопрос не имеет смысла, пожалуйста, простите меня.
Обновление: Под улучшением я имел в виду — простоту в использовании / понимании и, самое главное, простоту в обслуживании.
Ответ №1:
Я сомневаюсь в том, чтобы говорить о «лучшем» аспекте этого, но я использую AASM для своего конечного автомата рабочего процесса, и он прост в использовании, понятен и в остальном довольно крут.
Комментарии:
1. Под улучшением я имел в виду — простоту в использовании / понимании и, самое главное, простоту в обслуживании.
2. Тогда я бы предположил, что хороший конечный автомат gem проще в использовании и понимании, но, в конце концов, в этом вопросе много субъективности 🙂
3. Спасибо за вашу помощь. Кажется, тогда я должен начать изучать конечные автоматы 🙂