Комментарии 15
Если не сложно - добавьте плз схемку архитектуры: кто кого тыкает и кем погоняет.
Как раз на выходным разбирался с архитектурой хомяка (у меня Vue + fabricJS), остановился на MVP + нашлепка к презентеру в виде менеджера (у меня объекты - это несколько объектов fabricJS со своими методами).
PS Правда у меня скилл программирования небольшой (хорошо если уровень джуна).
MVP очень приятный паттерн. Работал с ним во времена WinForms лет 15 назад.
Мы тогда тоже использовали подход, когда view дергает методы presenter'a, но потом перешли к более удобному и, на мой взгляд, правильному варианту: view не знает ничего о presenter'e и генерит события. Presenter подписан на эти события и реагирует. На события также может быть подписан mediator, который как раз имеет право дергать методы presenter'ов, потому что знает о них, чтобы реализовать реакцию одной view, на события другой.
У вас, я так понял, есть шина событий, не думали о таком варианте?
В этом что-то есть, но я пока не могу придумать чем это может быть полезным? События сложнее отследить в отличии прямого доступа к презентеру. К тому же каждый компонент имеет право обратиться только к своему призентеру.
И в IDE быстрые переходы и рефакторинг работает
Если я правильно помню, мы событиями решали проблему общения с медиатором, так как он реагировал на события напрямую. Ну, и с архитектурной точки зрения view-компонент, как мне кажется, более правильно выглядит: я умею показывать данные, которые мне дают и сообщаю о том, что у меня что-то произошло, но больше ни о чем я не знаю.
Проблема вызова только своего presenter'a решалась с помощью настроенной шины событий, которая представляла собой дерево, где корень - это медиатор, а лист - view. соответственно событие, всплывая от view просто не могло попасть к чужому presenter'у.
Ваш вариант тоже вполне рабочий и если с ним нет проблем - почему нет?
Я так понимаю, что MVP - это больше про внутреннее устройство компонента. У нас тоже также: View ничего не знает о моделях, а модель не знает о view. Ссылка на presenter во view не передается. Presenter связывает model и view. При этом, допускается, что view может иметь свою внутреннюю независимую модель для хранения вьюшных данных. Presenter же получает всю информацию благодаря event-bus. То есть по логике прямо или косвенно eventEmitter должен быть и у view, и у model.
Я бы ещё выделил некий виртуальный слой public api для компонента. Чаще всего свойства и методы такого public api будут ссылаться на аналогичные для модели. Но также в этом слое могут быть методы для отслеживания синтетических событий, которые формируются в Presenter. Наличие синтетических событий также ведут к выводу о том, что presenter тоже должен иметь свой eventEmitter.
Mediator - это управление связью между компонентами. Вся БЛ взаимодействия содержится тут. Правильнее было бы говорить не о доступе к кишкам компонента, а управление ими через их public api.
Стандартные подходы Vue, где во Vuex экшенах делаются запросы и кладутся в стор и т.п не расширяемые
Мне тоже всегда виделось, что это плохо масштабируется. Поэтому вынес из стора обращения к сервисам в отдельный слой, похожий на описанный у вас презентер. Правда на React пишу, но они с Vue довольно похожи.
Вы сделали пол-шага к Clean Architecture. Я бы добавил inversifyjs для менеджмента зависимостей и заменил vuex на rxjs.
Незачем rxjs там где всё построено на реактивности) inversifyjs норм тема, изучу)
привет с митапа) можешь, плиз, гитхаб добавить?
Frontend архитектура MVP (Model-View-Presenter)