Модель пассивного просмотра: связь между компонентами

Question

Я рассматриваю каждую триаду MVP как отдельный компонент. Например, если View реализует интерфейс IView, докладчик, конечно, знает только View через IView.

Это то, что я могу сделать компонентом максимально пригодным для повторного использования. Теперь я должен объединить эти компоненты MVP, чтобы сформировать приложение. Мне интересно, какова хорошая практика, чтобы эти компоненты были как можно более разделены. Но, конечно, мне нужно, чтобы они общались / реагировали друг на друга.

Могу ли я просто сделать IView доступным для докладчиков других? Или я должен просто позволить докладчикам общаться друг с другом, не зная о базовых представлениях?

Спасибо

Answer 1

В MVP я вижу выступающих как организаторов деятельности.Как таковые они являются естественным выбором, на котором основывается композиция приложения.

Предоставление представления докладчику другим докладчикам нарушает идею инкапсуляции в шаблоне MVP.Хотя это не уменьшает возможность повторного использования компонента, предоставляющего его представление, оно уменьшает возможность повторного использования компонента, использующего представление другого компонента, так как увеличивает зависимости компонентов.

Поэтому я бы оставил представления частными длядокладчики и только позволяют докладчикам общаться друг с другом.

---

Разработка в ответ на комментарий

Когда я говорю, держу представление закрытым для докладчика, яозначает личное: не подвергается воздействию внешнего мира, кроме как при посредничестве ведущего.Конечно, докладчик может раскрыть методы для внешнего мира, которые заставят его манипулировать своим взглядом.Если докладчик делает это через интерфейс, он может фактически использовать свое собственное представление в качестве делегата для реализации интерфейса, но - вопреки тому, что вы предлагаете - докладчик делегирует содержимое представлению, а не наоборот.

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

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

Единственный кодЯ имею в виду уведомления его докладчику о том, что сделал пользователь (также известный как жесты пользователя в некоторых обсуждениях MVP).Это зависит от докладчика, чтобы решить, что с этим делать.Я также сохраняю всю логику о том, какие элементы управления включить / отключить в ответ на выбор пользователя в докладчике, а не в представлении.Это не только сохраняет всю логику взаимодействия в презентаторе, но и помогает создавать пользовательские интерфейсы (формы), тестируемые модулем.

Answer 2

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

a хороший пример это архитектура gwt mvp и более новая версия .