MVC в приложении на основе документов Какао
Сейчас я прохожу рефакторинг и реорганизацию своего приложения. Я понял, что некоторые различия между моделями и представлениями и их контроллерами уменьшились, и я хотел бы провести некоторую очистку.
У меня есть несколько ключевых классов, используемых в моем приложении: NSPersistentDocument, NSWindowController и класс модели.
Класс NSPersistentDocument действует как "модель-контроллер"; он владеет экземпляром класса модели и управляет всеми взаимодействиями с моделью.
Класс NSWindowController действует как "view-controller"; он владеет главным окном и управляет взаимодействием представлений в главном окне. Этот класс также является владельцем файла для файла пера, в котором определено окно.
Проблема, которую я вижу здесь, заключается в том, что у меня нет настоящего "контроллера". Мой нынешний дизайн заставляет модель-контроллер и контроллер представления знать друг о друге. Между этими двумя объектами нет медитирующего объекта, и из-за этого моя модель и представление четко не разделены, что делает проблему поддержки нескольких представлений или моделей проблемой.
Я хотел бы перенести функциональность обоих существующих контроллеров в новый класс "контроллер", который будет действовать как контроллер между контроллером модели и контроллером вида. В конце концов, это все еще только шаблон проектирования MVC, с чуть большей структурой.
Однако мне трудно понять, как это вписывается в архитектуру приложений на основе документов Cocoa.
Самый большой вопрос, который у меня есть, это где и как будет создан этот новый объект контроллера? Как это вписывается в архитектуру Какао? Я борюсь против архитектуры Какао, и есть ли лучший способ сделать это?
Благодарю.
2 ответа
Великолепные инстинкты наличия "контроллера модели" и "контроллера представления". Это очень хорошая ментальная таксономия того, как М и В обычно держатся вместе. Но, как вы заметили, у вас все еще может быть чистый "C" в MVC, чтобы связать всю операцию вместе.
Если вы говорите об одном контроллере для приложения: думайте о контроллере (big-C) как о том, что вытекает из функции main() вашего приложения - в старых руководствах по Какао этот объект часто называют AppController. Это может быть делегат UIApplication или нет, но если это не так, вы должны рассмотреть возможность создания такого главного контроллера в applicationDidFinishLaunching: метод делегата приложения в вашем проекте. Этот AppController может затем установить (и владеть) объектами модели и установить (и владеть) корневой контроллер представления, из которого вытекает ваш пользовательский интерфейс.
Если вы говорите о каком-либо компоненте-посреднике, у которого есть несколько экземпляров, по одному на каждую "пару" модель / представление в архитектуре документа, то просто создайте что-то подобное. DocumentController это название, которое вы хотите, хотя у Cocoa есть одно из тех, которые уже могут или не могут отражать тот тип функциональности, который вам нужен. "DocumentManager" - другое имя кандидата.
Звучит так, будто вам нужно взять копию Образцов Какао-дизайна, ответить на эти вопросы, а затем и на некоторые.
Глава 2 посвящена шаблону MVC с использованием ArrayController в качестве контроллера модели (а не постоянного контроллера модели документа, который вы используете).