Комментарии 14
Если не сложно - добавьте плз схемку архитектуры: кто кого тыкает и кем погоняет.
Как раз на выходным разбирался с архитектурой хомяка (у меня 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'у.
Ваш вариант тоже вполне рабочий и если с ним нет проблем - почему нет?
Стандартные подходы Vue, где во Vuex экшенах делаются запросы и кладутся в стор и т.п не расширяемые
Мне тоже всегда виделось, что это плохо масштабируется. Поэтому вынес из стора обращения к сервисам в отдельный слой, похожий на описанный у вас презентер. Правда на React пишу, но они с Vue довольно похожи.
Вы сделали пол-шага к Clean Architecture. Я бы добавил inversifyjs для менеджмента зависимостей и заменил vuex на rxjs.
Незачем rxjs там где всё построено на реактивности) inversifyjs норм тема, изучу)
привет с митапа) можешь, плиз, гитхаб добавить?
Frontend архитектура MVP (Model-View-Presenter)