Межкомпонентная связь в представлении (MVC)

Question

Каковы некоторые рекомендации по организации взаимодействия между сложными компонентами, которые есть в вашем представлении?

Я не говорю о простых виджетах, таких как поле со списком или элемент управления сеткой, но о компонентах, которые состоят из нескольких виджетов и могут заслуживать самостоятельного тестирования модулем.

Вы бы:

1. Определить абстрактные интерфейсы для каждого компонента, позволить контроллеру подключить их через внедрение зависимостей, чтобы они могли напрямую общаться друг с другом через вызовы методов? Таким образом, компонентам известны интерфейсы других компонентов.
2. Определить события, которые может запускать каждый компонент, и разрешить контроллеру напрямую подключать их через прослушиватели событий друг к другу? Поэтому компоненты имеют обработчики событий, связанные с приемниками событий других компонентов.
3. Определить абстрактные интерфейсы для каждого компонента, определить события, которые они могут запускать, и позволить контроллеру прослушивать все события и выполнять вызовы методов на интерфейсах? Компоненты, следовательно, абсолютно не зависят от других компонентов.
4. Классическое применение шаблона Observer?
5. Что-нибудь еще?

Обновление: Я вычеркнул "let the Controller ..." из # 1-3, потому что это не обязательно контроллер, который должен выполнять маршрутизацию / оркестровку в этих случаях. Это может быть само представление.

Я принял метод № 3 в недавнем проекте, и я был рад отделению и индивидуальной проверке компонентов. Однако у меня есть ощущение, что я могу упростить подключение компонентов. В моем случае основной объект View должен добавить несколько слушателей событий для каждого компонента, а затем вызывать методы для соответствующих компонентов, иногда выполняя некоторую локальную обработку (например, общение с моделью). Код для добавления обработчиков событий выглядит немного грязно, и я особенно ищу чистый способ сделать это.

Answer 1

Вариант № 3 звучит как шаблон посредника и часто является лучшим подходом, когда логика обновления и связь между объектами сложны. Он также имеет дополнительное преимущество, заключающееся в сохранении логики управления и централизации инициализации, что облегчает отслеживание и отладку таких случаев.

Answer 2

Похоже, у вас есть знания, чтобы ответить на свой вопрос по этому вопросу, но, возможно, просто не хватает уверенности, чтобы погрузиться. Вы просто исследуете или застряли где-то?

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

Я также позволил этому объекту менеджера выступать в качестве прокси для сети, которую я ждал, чтобы сложность стала выше, прежде чем я присоединился к SRP и сделал эту ответственность своим собственным классом.

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