Koenig, у mvc событийная модель запутанная, согласен. Сам далеко не сразу в нее въехал.
Если на пальцах то нужно два объяснения:
1. Событийная модель в общем
Смысл здесь в том, чтобы использовать события не просто как точки для реакции на работу алгоритма (обычно события используются именно так), а как точки "включения" в этот алгоритм. Вот пример:
class Router{
...
public function route($uri){
// Событие для разделения URI на части
$uriComponents = $this->eventManager->trigger('prepare', ['uri' => $uri]);
// Событие для роутинга по частям URI
$controller = $this->eventManager->trigger('route', ['uri' => $uri, 'components' => $uriComponents]);
return $controller;
}
}Класс с такой моделью это как паттерн "Шаблонный метод", но работающий через события (то есть более гибкий и динамический). Ты можешь навешать на события пачку обработчиков, который будут получать и обрабатывать URI и тот из них, кто первым вернет результат, и будет использоваться роутером для работы.
Модель сложная, не очевидная, но очень гибкая, потому применяют ее редко и по минимуму.
2. ZendMVC
Логика совершенно такая же, объект MVC просто генерит пачку событий, а всякие службы эти события ловят и обрабатывают, тем самым запуская приложение (вызывая роутер, затем контроллер, затем шаблонизатор). Выгода тут в том, что модули Zend (которые ты пишешь) могут так же слушать эти события (регистрируясь в метода onBootstrap класса Module) и как то на них реагировать, подменяя работу роутера, на пример.
Навешивает все эти системные обработчики на ZendMVC объект логика, запрятанная под App::init() который у тебя вызывается обычно в index.php