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

#model-view-controller #design-patterns

Вопрос:

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

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

Не могли бы вы:

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

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

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

Ответ №1:

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

Ответ №2:

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

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

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

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