MVC: передать указатель модели на представление? - PullRequest
4 голосов
/ 28 февраля 2012

У меня работает приложение для iOS, и я пытаюсь очистить часть структуры кода и реализацию. Я хотел бы уточнить мое понимание MVC и улучшить мой код.

Вопрос: Допустимо ли передавать модель в UIView, чтобы представление могло отображать ее на основе состояний элементов модели?

Я обрисовываю пример ниже, но понимаю, что он может быть неясным, слишком утомительным для чтения и т. Д. Суть такова: если UIView не изменяет какие-либо значения в модели, нормально, что он сохраняет слабую ссылку на модель? (скажем, по сравнению с тем, чтобы всегда просить своего делегата вернуть временный указатель на модель).

- спасибо за любые комментарии!

Пример: представьте себе UIView, который представляет собой 10-этажное ЗДАНИЕ с 1 ОКНОМ на каждом этаже. МОДЕЛЬ для этого - NSArray, содержащий 10 экземпляров пользовательских окон WINDOW. Каждое ОК. имеет состояние (свет включен или выключен) и CGRect, представляющий положение ОКНА в общем прямоугольнике вида здания.

Контроллер для экземпляра BUILDING определяет размер представления здания (его фрейма) и всех объектов WINDOW, включая CGRect, его состояние и т. Д., Создавая модель NSArray. Затем я назначаю эту МОДЕЛЬ UIView для контроллера BUILDING (но сохранение является сильным свойством контроллера BUILDING).

UIView необходимо знать о состоянии ОКНА и CGRect, чтобы нарисовать представление в drawRect.

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

Ответы [ 2 ]

4 голосов
/ 28 февраля 2012

Вы на правильном пути.Но нет никакой причины для «слабой» ссылки на модель.Для него целесообразно иметь сильную ссылку на часть модели, которую он фактически отображает, если только вы не хотите часть данных модели, чтобы иметь возможность исчезать во время их отображения.Это было бы необычно.

Скажем, у меня есть вещь под названием WindowPaneView, которая отображает WindowPane (просто избегая путаницы с UIWindow здесь).Нет ничего плохого в том, что контроллер создает представление и передает ему строгую ссылку на WindowPane.Во многих случаях это очень хороший дизайн.

Что было бы неправильно для WindowPaneView, чтобы сделать запрос к Building, чтобы получить правильную информацию окна.Контролер должен поговорить с Building, поделится информацией и передать каждому WindowPaneView его Window.

Для 1018 * также было бы неправильно знать что-либо о WindowPaneView.Модель никогда не должна знать о взглядах.Безумие быстро спускается, когда это происходит.Но представления, безусловно, могут знать о конкретной части модели, которую они отображают напрямую.Только не больше.

1 голос
/ 28 февраля 2012

Лучший выбор будет зависеть от времени жизни рассматриваемых объектов.

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

Если ваш контроллер не владеет объектом модели (что может легко произойти в приложении со многими различными взаимодействующими объектами контроллера), тогда у вас есть два варианта:

  1. Сохраните сильную ссылку на NSArray
  2. Содержит копию (возможно, глубокую копию) объекта NSArray, который затем используется объектом NSView столько времени, сколько необходимо.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...