Я читал о Model View Controller, Model View Presenter, Model View ViewModel и т. Д., И, как правило, базовая концепция кажется довольно простой для понимания: держать красивые визуальные элементы и интуитивно понятные элементы как отдельные и неосведомленные друг от друга, как возможно. Никакой логики арахисового масла в дизайне шоколада; круто, мне это нравится
Проблема в том, что я все еще немного неясен с этой третьей частью ... не с моделью или видом. Кажется, что у каждого есть свое представление о том, как его назвать, что он должен делать, что правильно, что просто неправильно ... и я схожу с ума, пытаясь выяснить, когда Presenter становится ViewModel и когда View не должен ' делать это, потому что это работа докладчика и ...
Я болтаю
Вместо того, чтобы просить кого-то объяснить разницу между ними - потому что это уже было сделано снова и снова (я знаю; я прочитал больше статей, чем могу сосчитать) - мне было бы любопытно услышать мысли о Несколько программистов на модели, которую я сам собрал вместе.
Тем не менее, что бы вы классифицировали этот дизайн как, и, возможно, что более важно, вы видите что-то об этом, что явно отстой? Конечно, я хотел бы услышать, что у меня все хорошо, если это действительно солидный дизайн, но я бы предпочел дать твердый совет, а не похвалу.
Примечание: я буду использовать «Мост» для загадочной третьей части Model-View-? чтобы избежать подсознательных предположений о том, что это «должно» быть.
модель
- Является ли авторитет данных.
- Получает информацию о запрошенных изменениях от Моста.
- Содержит и выполняет всю логику того, как данные связаны с другими данными.
Информирует Мост при изменении данных (для данных Мост проявил интерес).Редактирование формулировки: позволяет внешним подписчикам (о которых он ничего не знает) контролировать свое состояние или результаты расчетов.- Имеет нулевое знание о View.
Посмотреть
- Это связано с предоставлением пользователю возможности просматривать и манипулировать данными.
- Получает информацию об обновлениях данных с моста.
- Содержит и выполняет всю логику для представления данных и элементов управления пользователю.
- Информирует Мост, когда пользователь выполнил действие, которое (возможно) влияет на Модель.
- Информирует Мост, какая информация ему интересна.
- Имеет нулевые знания о модели.
Мост
- Является координатором и переводчиком между моделью и представлением.
- Вносит любые соответствующие изменения форматирования в информацию, передаваемую между моделью и представлением.
- Сохраняет информацию о том, «кому что нужно знать».
- Обладает знанием как модели, так и вида.
Дополнительные замечания
- В более сложных программах обычно существует несколько Моделей. В этой ситуации мост, как правило, берет на себя работу по координации / переводу между несколькими моделями и, таким образом, становится авторитетом в отношении того, для чего должны быть построены модели Protocall / API / design. (Например, если вы строите программу для карточных игр, и вы хотите построить модель перетасовки другой колоды, вы должны использовать Мост для определения того, какие функции необходимы для правильной связи с Мостом.)
- В небольших простых программах с одним видом и моделью мост обычно «принимает», какие функции доступны с обеих сторон. Однако, поскольку программы становятся более сложными, рекомендуется, чтобы Представления и Модели сообщали о своих функциональных возможностях Мосту, чтобы он мог избежать неэффективности и ошибочных предположений.
Я думаю, что это примерно так и есть. Безусловно, я приветствую любые вопросы, которые у вас могут возникнуть по поводу дизайна, который я склонен использовать, и я также приветствую любые предложения.
И как всегда, спасибо за ваше время.
источник
Ответы:
Твоя фраза
указывает, что ваш мост является ведущим в архитектуре MVP.
MVP и MVC очень похожи, за исключением того, что в MVP только Ведущий наблюдает за Моделью, в то время как в MVC Представлению также разрешено непосредственно наблюдать за Моделью (без Презентатора как «Моста»).
Ваша модель ответственности
возможно, неправильно сформулирован или, возможно, является ошибкой: вы не хотите, чтобы Модель имела зависимость ни от Bridge / Presenter / Controller, ни от View. Вместо этого вы используете либо шаблон наблюдателя, либо события, либо реактивное программирование, чтобы позволить мосту подписаться на изменения в модели. И тогда вы можете перефразировать свою ответственность как:
Если ваша модель не зависит от вашего контроллера или представления, ее проще тестировать и она гораздо более переносима.
источник
Я подозреваю, что одна из вещей, которые смущают вас, - это то, что есть два совершенно разных шаблона, которые обычно называют модель-представление-контроллер.
Это оригинал, реализованный в smalltalk и полезный для локальных систем графического интерфейса, и есть то, что я склонен считать web-mvc, который обменивает некоторые обязанности представлений и контроллеров, так что контроллеры могут сидеть на сервере с представления на клиенте (возможно, в виде html или через ajax).
Ваше описание звучит для меня так, будто оно соответствует большинству определений web-mvc.
источник
В сообществе программистов много обсуждают эту точную номенклатуру. Никто, кажется, не согласен ни о чем.
Для меня то, как мост соединен с видом, в основном определяет название.
Иногда все не так ясно. Например, докладчик может быть связан с составным представлением, состоящим из нескольких подпредставлений, или контроллер может быть создан без каких-либо знаний о его представлениях. Несмотря на это, я думаю, что мои правила - хорошее начало.
Как примечание, я хотел бы распределить обязанности следующим образом:
модель
Основная ответственность: постоянные данные.
Вторичные роли: проверка обновлений, уведомление наблюдателей об обновлениях.
Посмотреть
Основная ответственность: представить данные
Вторичные роли: принять ввод, представить UX
Мост
Основная ответственность: обновление данных.
Вторичные роли: очистка ввода, синхронизация данных и представлений.
источник
Несмотря на то, что предложенный вами шаблон выглядит правильным на первый взгляд и, несомненно, будет работать для небольших экземпляров, поскольку ваше приложение становится все более сложным, вы столкнетесь с проблемами, когда вы не уверены, какие обновления, что, кто слушает, где и почему я пытаюсь контролировать столько моделей из множества видов, всех, кому нужен доступ друг к другу и т. д.
Я рекомендую расширить ваши идеи, используя следующую схему (взято из выступления Эми Паламантон « Враг государства» ):
модели
Взгляды
Контроллеры
Модули
Менеджер по расположению
диспетчер
заявка
Этот тип паттерна позволяет вашему приложению быть компонуемым, тестироваться модульно, устраняет сложность, которую мост создает со временем, хорошо разделяет проблемы и т. Д.
Как указывает Эми: будьте осторожны, чтобы не построить сервер на клиенте. И будьте осторожны, чтобы не впасть в доктрину "Я делаю каркас MV *, поэтому я должен ___!" Вместо этого возьмите все эти идеи (и другие ответы здесь) и найдите, что лучше всего подходит для вашего приложения и команды.
Я настоятельно рекомендую посмотреть выступление Эми Паламантайн « Враг государства» (из которого вышли эти идеи) или, по крайней мере, просмотреть слайды из выступления .
источник