Организация iOS проекта для шаблона проектирования MVC

Question

Я работаю над многоцелевым приложением для iPhone, и в настоящее время мои представления (VIEW) настроены и их переходы (CONTROLLER?) Работают нормально. Теперь я хотел бы добавить объекты для фактических данных программы (MODEL).

Мой вопрос: Как мне структурировать данные, чтобы они соответствовали шаблону проектирования Model View Controller (MVC)? Я знаю, что должен создать отдельные классы для реализации своих структур данных, и что мои классы контроллеров могут передавать им сообщения из представления, но есть ли другие организационные соображения, которые я должен рассмотреть? Особенно те, которые касаются Cocoa Touch, Xcode или iOS?

Другие подробности: Воспроизведение предварительно записанного и, возможно, сгенерированного пользователем звука также будет иметь важное значение. Я знаю, что это элементы модели, но как именно они связаны с буквой "V" и буквой "C", я все еще немного размыт. Я полагаю, когда пользовательское действие требует воспроизведения звука, КОНТРОЛЛЕР должен передать сообщение в МОДЕЛЬ, чтобы подготовить соответствующие звуки, но где именно должно регулироваться воспроизведение в реальном времени? В "PlayerController" отдельно от ViewController я представляю?

Огромное спасибо и простите за мое неверие в MVC.

Answer 1

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

• Клип (M) - Ответственный за хранение фактических аудиоданных. Он будет знать, как интерпретировать данные и информацию о них, но на самом деле он ничего не будет воспроизводить.

• Player (V) - фактически воспроизводит клип на динамиках. Да, это что-то вроде view в MVC. Аудио это просто другой вид презентации. Тем не менее, вы никогда не назовете его «PlayerView», потому что это предполагает, что это подкласс UIView.

• PlayerView (V) - представление проигрывателя на экране. Ничего не знает о клипах.

• ClipManager (C) - объект, который будет отслеживать все клипы в системе и управлять извлечением их из сети, добавлением и удалением их в кэшах и т. Д.

• PlayerViewController (C) - извлекает клип из ClipManager и координирует Player и PlayerView для его отображения и воспроизведения, а также любые другие элементы пользовательского интерфейса (например, «кнопка возврата» или тому подобное).

Это всего лишь пример того, как вы можете разбить его на какое-то теоретическое приложение аудиоплеера. Есть много правильных способов MVC сделать это, но это один из способов думать об этом.

Answer 2

Лорд Джон Ворфин (и, я уверен, кто-то до него) сказал: «Характер - это то, что вы есть во тьме». Что ж, модель - это то, чем является приложение, когда никто не смотрит - именно данные и логика определяют, как приложение ведет себя независимо от того, как оно представлено на экране.

Представьте, что вы решили добавить интерфейс командной строки в свое приложение. Вы по-прежнему хотели бы использовать те же структуры для управления вашими данными, и ваша логика для сортировки, просеивания и вычисления на основе данных также должна быть такой же. Код в вашем приложении, который остается важным / полезным независимо от того, как пользователь видит приложение или взаимодействует с ним, является моделью.

Модель может быть очень простой и полностью состоять из стандартных объектов. Приложения для iOS часто больше ориентированы на извлечение, хранение и отображение данных, чем на сжатие чисел, поэтому весьма обычно иметь модель, которая представляет собой просто массив словарей или иерархию словарей, которая имеет несколько уровней. Если вы посмотрите на класс NSManagedObject Core Data, он во многом похож на NSMutableDictionary. Так что не бойтесь использовать стандартные объекты, если они уместны.

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

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

Надеюсь, это поможет.