Комментарии 17
Спасибо, хорошая тема поднята. Я только не уловил, как запускаются процессы в стандартной ситуации (помимо исключительного случая запуска руками). Опять же колбэком?
Не обязательно. Процессы можно запускать откуда угодно. Можно например из контроллера — создали ресурс (ордер, например) — и для него запустили процесс.

RailsWorkflow::ProcessManager.start_process(
  process_template_id , { resource: resource }
)
Паттерну «Команда» (http://c2.com/cgi/wiki?CommandPattern ) уже 20 с гаком лет. Организуйте команды в очереди и ваши проблемы будут решены
Речь не об отдельном паттерне. Организуйте команды в очереди, возможность гнать их синхронно-асинхронно, пользовательские команды (пользуясь вашей терминологией), добавьте возможность конфигурировать «очереди», отслеживать «свалившиеся» очереди, экспорт-импорт очередей, поддержку версий конфигурации с учетом еще не завершенных процессов на старой версии конфигурации и т.д. В общем я не о реализации отдельно взятого паттерна а о движке на основе этой идеи.
Паттерну 20 лет — а попробуйте найти нормальный движок на рельсах — и упретесь в то что его почему-то нет. Гемов для callback-ов — всяких state machine и прочих модификациях — полно. А чего-то посложнее — почему-то нет.
Не нужно усложнять задачу, для rails приложения не нужны все эти экспорт-импорт. Есть кролик с его amqp, который для этого создан. Остается только проблема с приведением в порядок логики rails-приложения. Тут классы шаблоны команд и единый синглтон-очередь пишется за час (отлаживается еще час). Однако в rails этого нет не потому-что это сложно, а потому-что там учат работать на коллбэках и использовать по максимуму стандартный код. Переделывать рельсы под себя и внедрять какую-то архитектуру в обход стандарта считается дурным тоном.
Далеко не всем это нужно — согласен. Но скатываться во флуд из разряда «учат работать на колбэках и использовать по максимуму стандартный код» — не хочу. Если не нужно — значит не нужно. Кому-то DYI не нужно, а кто-то занимается. Каждому свое.
>> там учат работать на коллбэках
А там не учат, как потом поддерживать такое приложение?
А что за выпад в мою сторону такой? Может они специально на коллбэках пишут что-бы потом $ рубить на поддержке. Я в тему глубоко не копал, посчитал необходимым обозначить уже готовое решение под озвученную тему, в чем проблема?
Не хотел вас задеть. В коллбеках проблема, наплакались кровавыми слезами в свое время.
Рекомендую интересующимся данной темой посмотреть Architecture the Lost Years by Robert Martin
Не совсем это про коллбеки… Но в рельсах очень много таких моментов.

А также рекомендую ознакомиться с блогами Роберта Мартина:
blog.cleancoder.com
blog.8thlight.com/uncle-bob/archive.html

С DHH (автором рельсов) у них занятный спор вышел
Вы сейчас открыли для себя новый чудный мир акторов, паттернов потоковой обработки и так далее :-) Сразу скажу, что эта история полностью альтернативна Rails, и вам будет очень сложно увязать одно с другим.

Это объясняет миграцию разработчиков с Rails на Erlang, Clojure, Scala и так далее. Однако сами по себе языки не панацея, интересна сама модель акторов, на которой построен принцип работы Erlang-приложений и фреймворк Akka.

Если интересно, можем пообщаться на эту тему, вам совершенно верно упомянули Роба Мартина и паттерны. DHH, к сожалению, все это отмел как «устаревшее» и в результате разработчики плачут кровавыми слезами, однако, щедро оплачиваемыми. Но эта лафа скоро может закончиться, потому что модель акторов сейчас становится модной, а это значит, что рельсы могут сдать свои позиции.
Пока что не вижу никакой сложности. Все очень спокойно ложится на рельсы. Они в общем-то никоим образом не мешают использовать паттерны. Проблема в том что большинство берет туториалы по рельсам — и как в них описано — так и пишут (пример — те же callback-и).
Попробуйте написать код, который полностью удовлетворяет SOLID на рельсах :-)

Ну и модель акторов вы туда никак не прикрутите при всем желании.
Не совсем понятна постановка вопроса :) «Попробуйте прикрутить». Вопрос — зачем? Я исхожу из задачи — отделить бизнес логику от моделей / контроллеров, сформировать из отдельных операций какой-то ход процесса и дать возможность с процессом работать (мониторить, саппортить и т.д.).
В программировании очень много принципов, подходов и т.д. — что ж их все пробовать прикрутить? У меня есть задача, есть вариант решения. О нем и речь.
Никто не говорит, что надо прикручивать все подряд. Но если начать как следует копать, то выяснится, что единственный математически обоснованный способ писать расширяемый код на современных вычислительных системах — это модель акторов. И это, конечно, не описывается словом «прикрутить» в обычном понимании этого слова. Оно возникло только из сочетания с рельсами. Потому что там либо выкинуть все рельсы, либо «прикрутить».

У вас просто есть два пути. Первый — пробовать все самому, решая все усложняющиеся задачи и придя в итоге к той же модели, но через год или больше. Второй — попробовать узнать побольше, разобраться в теории и существенно сократить этот путь, повысив качество решений, которые вы сможете создавать. Выбор, безусловно, за вами :-)
По поводу модели акторов — вроде как народ изголяется — https://github.com/celluloid/celluloid. Мне сложно судить насколько это удачное / неудачное решение но тем не менее оно есть.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.