Правильный дизайн модели -_____

Я читал о 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

Мост

Основная ответственность: обновление данных.
Вторичные роли: очистка ввода, синхронизация данных и представлений.

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

Я рекомендую расширить ваши идеи, используя следующую схему (взято из выступления Эми Паламантон « Враг государства» ):

модели

• Синхронизировать состояние с хранилищем данных
• Обработка проверки новых / обновленных данных
• Поднимать события, когда они меняют состояние

Взгляды

• Визуализировать шаблоны
• Обработка событий модели
• Обрабатывать события DOM
• Опосредует взаимодействие между моделью и DOM

Контроллеры

• Управляет максимум парой моделей и представлений
• Отслеживает просмотры в контейнере

Модули

• Логическая группировка контроллера и его представления и модели
• Тестируемые
• Маленький и ремонтопригодный (единая ответственность)
• Координирует (через контроллер) состояние и события представлений и моделей, которые он содержит
• Свободно представлять свои собственные взгляды
• Не свободно выбирать, где представить свои виды

Менеджер по расположению

• Ответственный за верстку композиции
• Определяет оболочку приложения в DOM с областями, в которых Модули могут представлять свое содержимое

диспетчер

• Прослушивает события (через глобальный поток PubSub)
• Ответственный за загрузку новых модулей на основе событий
• Передача загруженных модулей в менеджер макетов
• Управляет всем временем жизни модуля (создание, очистка, кэширование и т. Д.)
• Примеры событий:
  • Изменения маршрута (включая начальный маршрут загрузки)
  • Взаимодействие с пользователем
  • Событие модуля вызвано событием модели из-за изменения состояния на стороне сервера и т. Д.

заявка

• Отвечает за общую настройку, реализует такие вещи, как:
  • диспетчер
  • маршрутизатор
  • PubSub поток
  • Лесорубы
  • и т.д

Этот тип паттерна позволяет вашему приложению быть компонуемым, тестироваться модульно, устраняет сложность, которую мост создает со временем, хорошо разделяет проблемы и т. Д.

Как указывает Эми: будьте осторожны, чтобы не построить сервер на клиенте. И будьте осторожны, чтобы не впасть в доктрину "Я делаю каркас MV *, поэтому я должен ___!" Вместо этого возьмите все эти идеи (и другие ответы здесь) и найдите, что лучше всего подходит для вашего приложения и команды.

Я настоятельно рекомендую посмотреть выступление Эми Паламантайн « Враг государства» (из которого вышли эти идеи) или, по крайней мере, просмотреть слайды из выступления .