Тарас Сереванн: почему же? Там тоже может быть и маршрутизация (какие сообщения какой код обрабатывает) и контроллер (обработка сообщений и конвертация данных из одного представления в другое).
Вы лучше больше деталей о этом коде укажите. Как он запускается (скорее всего это cli скрипт, так?), из чего состоит (это же не один "класс"?).
alestro: вот этот $next может быть опциональным аргументом. Да и функции я приводил просто для примера, это может быть объект где $next вообще в конструктор передается и тогда с интерфейсом вообще никаких проблем.
А в варианте с функциями next можно "спрятать" за счет каррирования.
twopizza: вы объясните зачем вам их вообще "определять"? Статус задачи хранится в очереди. Как только задача получает статус done она вылетает из очереди.
twopizza: ну мол после того как воркер успешно доставил сообщение добавлять в базу данных в лог информацию об этом. Ну или держать отдельную таблицу для нотификаций и менять им статус (но как по мне это странно). Словом... cron не нужен. нужны очереди. А все остальное зависит от деталей задачи.
walkaway: нет. Повторюсь - проверяйте что попадает в $scope на момент возникновения ошибки. Просто берем и ставим бряку в коде там, где кидается ошибка.
twopizza: зависит от задачи. Например нам важно отслеживать статус (прочитал чувак оповещение или нет), но если мы говорим о email-ах то в этом уже нет смысла так как... если он доставлен отслеживанием этого статуса будет заниматься email клиент.
Реализацию... есть минимум сотня способов это организовать даже если следовать пунктам которые я описал.
kolyalesha: почему не получится? Просто тогда у вас сущности будут знать о том как они хранятся, что в большинстве случаев не страшно но нужно понимать чем это чревато.
В этом случае вам придется прокидывать зависимость как-то самостоятельно. Как именно - решать вам. Это уже будет не совсем стандартная штука.
