Принцип единой ответственности и Backbone.View

Я использую Backbone.js. У меня есть popup1, который создает popup2. popup2 является компонентным, и когда он закрывает его, запускается событие «school_address: saved». Мне нужно отправить запрос на сервер на мероприятие «school_address: saved». Я поместил обработчик, который делает это в представлении popup1 (его экземпляр все еще существует), но я не уверен, что это место подходит, потому что представления несут ответственность за логику шаблона UI, не так ли ?.Принцип единой ответственности и Backbone.View

Как вы думаете, что лучше всего подходит для такого кода? И что бы это было, если я использовал Marionette.js?

источник

2015-10-05 dortonway

У вас есть модель в ваших взглядах? Может быть этот «запрос на сервер» связан с данными в модели? Если это так, я думаю, что лучшим местом для этой логики является внутри модели, и представления будут просто прослушивать события в этой модели. – antejan

У вас есть модель в ваших взглядах? - Да, в каждом всплывающем окне. Но из-за «компонентной» природы popup2 я не могу изменить свою модель, потому что этот запрос на событие popup2 необходим только тогда, когда popup1 создает экземпляр popup2. – dortonway

Может быть этот «запрос на сервер» связан с данными в модели? Нет, это пустой запрос. Чтобы предупредить сервер, этот popup2 был обработан. – dortonway

Мы используем BackboneJS в течение нескольких лет, и задавались вопросом о подобных случаях в прошлом ...

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

Однако, поскольку эти всплывающие окна/«модальности приложения», я думаю, что это поможет, если вы считаете, следующие на основе текущей потребности:

Если это ТОЛЬКО popup1, который может создать экземпляр и отобразите popup2, затем включите popup1 listenTo события, вызванные popup2.
Если вы предусмотрели изменения вашего приложения и, возможно, включили отображение popup2 в другом месте или независимо, я бы предложил вам прослушать всплывающие события из представления на более высоком уровне (возможно, у вас есть маршрут для). таким образом, оба ваших всплывающих окна будут «независимыми», и вы сможете более легко перерабатывать свой код и поддерживать большую гибкость по мере роста вашего приложения.

источник

2015-10-05 13:42:00

Не только popup1 может создавать экземпляр и отображать popup2, но мне нужно отправить этот запрос, только если он popup1. Невозможно прослушать это событие в представлении на более высоком уровне, поскольку всплывающие окна могут быть созданы в разных «средах». Так что, согласно вашему ответу, я полагаю, что мой выбор был прав (разместить обработчик на всплывающем окне1). Но почему бы вам не подумать, что маршрутизатор уместен? – dortonway

в разных «средах» - Я имею в виду разные страницы. И из-за специфики проекта нет макета, и я не уверен, что такое место было бы уместным из-за его глобальности. – dortonway

Если это «общий» прослушиватель, ожидающий событий из popup2, вы можете разместить этот код почти везде. он не должен быть ни в коем случае - его можно просто привязать, используя глобальную функцию где-то, не обязательно изнутри маршрутизатора ... Если событие запускается из нескольких мест (не только изнутри popup2), я бы просто передайте другой аргумент вместе с полезной нагрузкой события, чтобы различать триггеры, выходящие из popup2 или из других мест в приложении, а также условие для функциональности события для проверки значения, указанного в полезной нагрузке. –

Принцип единой ответственности и Backbone.View

ответ

Смежные вопросы