Если пишут "комманда", то сразу понятно, что речь идет о паттерне, а если правильно пишут, значит не о паттерне. :away:

А названия топика недостаточно для понимания?

:rolleyes:
да, я неграмотный, простите

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

Как-то попахивает. Надо (ну или не надо ;)):
1. Юзер кликает логин.
2. Медиатор шлет событие.
3. Команда реагирует на событие и дергает сервис.
4. Сервис, если все нормально меняет модель или шлет событие / меняет модель, если что-то пошло не так.
5. Модель рапортует об изменении.
6. Медиатор реагирует на изменения.

1 - Это выходит грубоговоря на каждое действие юзера нужно создавать команду ? тоесть выходит 3 хендлера - первый ловит клик в самой вьюшке , второй в медиаторе(вьююшка послала ивент), и 3 - сама команда. Тогда будет немерянно команд и слушателей событий.
2 - сервис менять может модель ? может ли медиатор слушать изменения сервиса ?

(я понимаю что все это условности - но есть же практические наработки, помогите новичку плиз)

Robotlegs именно тем и хорош, что не заставляет вас делать что-то так или иначе, у вас полная свобода действий. А бестпрактис это каждый для себя сам уже нарабатывает, как оно удобнее, правильнее или быстрее или ... короче, это с опытом придет. Если сейчас вам удобно, то это уже можно считать правильным, позже сами поймете что вы делаете не так и почему.

1. медиатор сам может подписаться на клик вьюхи (но удобнее тут использовать сигналы), и сам шлет уже кастомное событие, которое поймает тот кому это нужно (например примапленная команда). Либо да, въюха шлет событие, медиатор ловит и сам шлет либо это же событие дальше, либо свое новое, но это каша и неудобно, но за то гибко.
2. может и может.