Контроллер представления модели
Шаблон разработки Контроллера представления Модели (MVC) довольно стар. Изменения его были вокруг, по крайней мере, с первых лет Smalltalk. Это - высокоуровневый образец, на который это интересуется общей архитектурой приложения и классифицирует объекты согласно общим ролям, которые они играют в приложении. Это - также составной образец, в котором это включает несколько, больше элементных образцов.
Объектно-ориентированные программы получают преимущества несколькими способами путем адаптации шаблона разработки MVC к их проектам. Много объектов в этих программах имеют тенденцию быть более допускающими повторное использование, и их интерфейсы имеют тенденцию быть лучше определенными. Программы в целом более адаптируемы к изменяющимся требованиям — другими словами, они более легко расширяемы, чем программы, которые не являются на основе MVC. Кроме того, много технологий и архитектуры в Какао — такой как привязка, архитектура документа и scriptability — основываются на MVC и требуют, чтобы Ваши пользовательские объекты играли одну из ролей, определенных MVC.
Роли и отношения объектов MVC
Шаблон разработки MVC рассматривает там, чтобы быть тремя типами объектов: объекты модели, объекты представления и объекты контроллера. Образец MVC определяет роли, которые эти типы объектов играют в приложении и их линиях связи. При разработке приложения существенный шаг выбирает — или создает пользовательские классы для — объекты, попадающие в одну из этих трех групп. Каждый из трех типов объектов разделяется от других абстрактными границами и связывается с объектами других типов через те границы.
Объекты модели инкапсулируют данные и основные способы поведения
Объекты модели представляют специальные знания и экспертные знания. Они содержат данные приложения и определяют логику, управляющую теми данными. Хорошо разработанное приложение MVC имеет все свои важные данные, инкапсулировавшие в объектах модели. Любые данные, которые являются частью постоянного состояния приложения (ли то постоянное состояние сохранено в файлах или базах данных) должны находиться в объектах модели, как только данные загружаются в приложение. Поскольку они представляют знания и опыт, связанные с определенной проблемной областью, они имеют тенденцию быть допускающими повторное использование.
Идеально, объект модели не имеет никакого явного соединения с пользовательским интерфейсом, используемым, чтобы представить и отредактировать его. Например, если у Вас есть объект модели, представляющий лицо (скажите запись адресной книги) Вы могли бы хотеть сохранить дату рождения. Это - хорошая вещь сохранить в Вашем объекте модели Лица. Однако хранение строки формата даты или другой информации о том, как та дата должна быть представлена, вероятно, более обеспечено где-то в другом месте.
На практике это разделение является не всегда лучшей вещью, и существует некоторая комната для гибкости здесь, но в целом объект модели не должен касаться проблем представления и интерфейса. Одним примером, где что-то вроде исключения разумно, является приложение получения, имеющее объекты модели, представляющие выведенную на экран графику. Это целесообразно для графических объектов знать, как привлечь себя, потому что главная причина для их существования состоит в том, чтобы определить визуальную вещь. Но даже в этом случае, графические объекты не должны полагаться на проживание в определенном представлении или любом представлении вообще, и они не должны отвечать за знание, когда привлечь себя. Их нужно попросить привлечь себя объектом представления, хотящим представить их.
Информация о настоящем объектов представления пользователю
Объект представления знает, как вывести на экран и мог бы позволить пользователям редактировать, данные от модели приложения. Представление не должно быть ответственно за то, что хранило данные, которые оно выводит на экран. (Это не означает, что представление никогда фактически хранит данные, которые оно выводит на экран, конечно. Представление может данные кэша или делать подобные приемы по причинам производительности). Объект представления может ответить за отображение всего одной части объекта модели, или целого объекта модели, или даже многих различных объектов модели. Представления прибывают во многие различные варианты.
Объекты представления имеют тенденцию быть допускающими повторное использование и конфигурируемыми, и они обеспечивают непротиворечивость между приложениями. В Какао платформа AppKit определяет большое количество объектов представления и обеспечивает многих из них в библиотеке Interface Builder. Путем многократного использования объектов представления AppKit, такой как NSButton объекты, Вы гарантируете, что кнопки в Вашем приложении ведут себя точно так же, как кнопки в любом другом приложении Какао, гарантируя высокий уровень непротиворечивости по внешности и поведения через приложения.
Представление должно гарантировать, что выводит на экран модель правильно. Следовательно, это обычно должно знать об изменениях в модели. Поскольку объекты модели не должны быть связаны к определенным объектам представления, им нужен универсальный способ указать, что они изменились.
Связь объектов контроллера модель к представлению
Объект контроллера действует как посредник между объектами представления приложения и его объектами модели. Контроллеры часто отвечают за проверку, что представления имеют доступ к объектам модели, которые они должны вывести на экран и действовать как кабелепровод, через который представления узнают об изменениях в модели. Объекты контроллера могут также выполнить задачи установки и координирования для приложения и управлять жизненными циклами других объектов.
В типичном Какао проект MVC, когда пользователи вводят значение или указывают выбор через объект представления, то значение или выбор, передается к объекту контроллера. Объект контроллера мог бы интерпретировать ввод данных пользователем некоторым специализированным способом и затем или может сказать объект модели, что сделать с этим вводом — например, «добавьте, что новое значение» или «удаляет текущую запись» — или это может иметь объект модели, отражают измененное значение в одном из его свойств. На основе этого того же ввода данных пользователем некоторые объекты контроллера могли бы также сказать объекту представления изменить аспект его появления или поведения, такого как сообщение кнопки отключить себя. С другой стороны, когда объект модели изменяется — говорят, к новому источнику данных получают доступ — объект модели обычно передает то изменение в объекте контроллера, тогда запрашивающем один или несколько объектов представления обновить себя соответственно.
Объекты контроллера могут быть или допускающими повторное использование или недопускающими повторное использование, в зависимости от их общего типа. Типы Объектов Контроллера Какао описывают различные типы объектов контроллера в Какао.
Объединение ролей
Можно объединить роли MVC, которые играет объект, делая объект, например, выполните обоих контроллер и просмотрите роли — когда, это вызвали бы контроллером представления. Таким же образом у Вас могут также быть объекты контроллера модели. Для некоторых приложений, комбинируя роли как это приемлемый проект.
Модельный контроллер является контроллером, интересующимся главным образом уровнем модели. Этому «принадлежит» модель; его основная ответственность состоит в том, чтобы управлять моделью и связаться с объектами представления. Методы действия, применяющиеся к модели в целом, обычно реализуются в модельном контроллере. Архитектура документа предоставляет много этих методов Вам; например, NSDocument объект (который является центральной частью архитектуры документа) автоматически обрабатывает методы действия, связанные с тем, чтобы сохранить файлы.
Контроллер представления является контроллером, интересующимся главным образом уровнем представления. Этому «принадлежит» интерфейс (представления); его основная ответственность состоит в том, чтобы управлять интерфейсом и связаться с моделью. Методы действия, касавшиеся данных, выведенных на экран в представлении, обычно реализуются в контроллере представления. NSWindowController объект (также часть архитектуры документа) является примером контроллера представления.
Руководство по проектированию для Приложений MVC дает некоторый совет проекта относительно объектов с объединенными ролями MVC.
Типы объектов контроллера какао
Связь Объектов контроллера Модель к Представлению делает набросок абстрактной схемы объекта контроллера, но на практике изображение намного более сложно. В Какао существует два общих вида объектов контроллера: посреднические контроллеры и контроллеры координирования. Каждый вид объекта контроллера связан с различным набором классов, и каждый обеспечивает различный диапазон способов поведения.
Посреднический контроллер обычно является объектом, наследовавшимся от NSControllerкласс. Посреднические объекты контроллера используются в технологии привязки Какао. Они упрощают — или промежуточный — поток данных между объектами представления и объекты модели.
Посреднические контроллеры являются обычно готовыми объектами, которые Вы перетаскиваете из библиотеки Interface Builder. Можно сконфигурировать эти объекты установить привязку между свойствами объектов представления и свойствами объекта контроллера, и затем между теми свойствами контроллера и определенными свойствами объекта модели. В результате, когда пользователи изменяют значение, выведенное на экран в объекте представления, новое значение автоматически передается к объекту модели для хранения — через посреднический контроллер; и когда свойство модели изменяет свое значение, то изменение передается к представлению для дисплея. Краткий обзор NSController класс и его конкретные подклассы —NSObjectController, NSArrayController, NSUserDefaultsController, и NSTreeController— обеспечьте поддерживающие функции, такие как возможность фиксировать и отбросить изменения и управление значениями заполнителя и выборами.
Контроллер координирования обычно NSWindowController или NSDocumentControllerобъект (доступный только в AppKit), или экземпляр пользовательского подкласса NSObject. Его роль в приложении должна наблюдать — или координата — функционирование целого приложения или части приложения, такого как объекты, разархивированные от файла пера. Контроллер координирования предоставляет услуги, такие как:
Ответ на сообщения делегации и наблюдение уведомлений
Ответ на сообщения действия
Управление жизненным циклом находящихся в собственности объектов (например, выпуск их в свое время)
Установление соединений между объектами и выполнение других задач установки
NSWindowController и NSDocumentController классы, которые являются частью архитектуры Какао для основанных на документе приложений. Экземпляры этих классов обеспечивают реализации по умолчанию для нескольких из служб, упомянутых выше, и можно создать подклассы их для реализации большего специализированного поведения. Можно даже использовать NSWindowController объекты управлять окнами в приложении, которое не является на основе архитектуры документа.
Контроллеру координирования часто принадлежат объекты, заархивированные в файле пера. Как Владелец Файла, контроллер координирования является внешним к объектам в файле пера и управляет теми объектами. Эти находящиеся в собственности объекты включают посреднические контроллеры, а также объекты окна и просматривают объекты. См. MVC как Составной Шаблон разработки для больше при координировании контроллеров как Владелец Файла.
Экземпляры пользовательских NSObject подклассы могут полностью подойти как координирование контроллеров. Эти виды объектов контроллера комбинируют и посредничество и координирование функций. Для их посреднического поведения они используют механизмы, такие как целевое действие, выходы, делегация и уведомления для упрощения перемещения данных между объектами представления и объектами модели. Они имеют тенденцию содержать много кода связующего звена и, потому что тот код исключительно специализирован, они - наименее допускающий повторное использование вид объекта в приложении.
MVC как составной шаблон разработки
Контроллер представления модели является шаблоном разработки, составленным из нескольких образцов более базовой конструкции. Эти основные образцы сотрудничают для определения функционального разделения и путей коммуникации, которые характерны для приложения MVC. Однако традиционное понятие MVC присваивает ряд основных образцов, отличающихся от тех, которых присваивает Какао. Различие прежде всего заключается в ролях, данных контроллеру и объектам представления приложения.
В исходной концепции (Smalltalk) MVC составлен из Составного объекта, Стратегии и Шаблонов «наблюдатель».
Составной объект — объекты представления в приложении являются фактически составным объектом вложенных представлений, сотрудничающих скоординированным способом (т.е. иерархия представления). Эти компоненты дисплея колеблются от окна для соединения представлений, таких как табличное представление, к отдельным представлениям, таким как кнопки. Ввод данных пользователем и дисплей могут иметь место на любом уровне составной структуры.
Стратегия — объект контроллера реализует стратегию одного или более объектов представления. Объект представления ограничивается поддержанием его визуальных аспектов, и это делегирует к контроллеру все решения о специализированном значении интерфейсного поведения.
Наблюдатель — объект модели сохраняет заинтересованные объекты в приложении — обычно просматривают объекты — советовавший относительно изменений в его состоянии.
Традиционным путем Составной объект, Стратегия и Шаблоны «наблюдатель» сотрудничают, изображен рисунком 7-1: пользователь управляет представлением на некотором уровне составной структуры, и, в результате событие сгенерировано. Объект контроллера получает событие и интерпретирует его специализированным способом — т.е. оно применяет стратегию. Эта стратегия может состоять в том, чтобы запросить (через сообщение) объект модели изменить свое состояние или запросить объект представления (на некотором уровне составной структуры) изменить свое поведение или появление. Объект модели, в свою очередь, уведомляет все объекты, кто зарегистрировался как наблюдатели когда его изменения состояния; если наблюдатель является объектом представления, он может обновить свое появление соответственно.
Версия Какао MVC как составной образец имеет некоторые общие черты традиционной версии, и фактически довольно возможно создать рабочее приложение на основе схемы на рисунке 7-1. При помощи технологии привязки можно легко создать Какао приложение MVC, представления которого непосредственно наблюдают, что объекты модели получают уведомления об изменениях состояния. Однако существует теоретическая проблема с этим проектом. Объекты представления и объекты модели должны быть большинством допускающих повторное использование объектов в приложении. Объекты представления представляют «стиль» операционной системы и приложений та система поддержки; непротиворечивость по внешности и поведение важны, и это требует очень допускающих повторное использование объектов. Объекты модели по определению инкапсулируют данные, связанные с проблемной областью, и выполняют операции на тех данных. Мудрый проектом, лучше разделять модель и просматривать объекты друг от друга, потому что это улучшает их возможность многократного использования.
В большинстве приложений Какао уведомления об изменениях состояния в объектах модели передаются для просмотра объектов через объекты контроллера. Рисунок 7-2 показывает эту различную конфигурацию, кажущуюся намного более чистой несмотря на участие двух образцов более базовой конструкции.
Объект контроллера в этом составном шаблоне разработки включает образец Посредника, а также Стратегическую модель; это добивается потока данных между моделью и объектами представления в обоих направлениях. Изменения в состоянии модели передаются для просмотра объектов через объекты контроллера приложения. Кроме того, объекты представления включают Шаблон «команда» посредством своей реализации механизма целевого действия.
Существуют практические причины, а также теоретические для пересмотренного составного шаблона разработки, изображенного на рисунке 7-2, особенно когда дело доходит до шаблона разработки Посредника. Посреднические контроллеры происходят из конкретных подклассов NSController, и эти классы, помимо реализации образца Посредника, предлагают много функций, которые приложения должны использовать в своих интересах, такие как управление значениями заполнителя и выборами. И если Вы решили не использовать технологию привязки, Ваш объект представления мог бы использовать механизм, такой как центр уведомления Какао для получения уведомлений из объекта модели. Но это потребовало бы, чтобы Вы создали пользовательский подкласс представления для добавления знания уведомлений, отправленных объектом модели.
В хорошо разработанном Какао приложению MVC, координируя объекты контроллера часто принадлежат посреднические контроллеры, архивирующиеся в файлах пера. Рисунок 7-3 показывает отношения между двумя типами объектов контроллера.
Руководство по проектированию для приложений MVC
Следующие инструкции применяются к соображениям Контроллера представления Модели в проекте приложений:
Несмотря на то, что можно использовать экземпляр пользовательского подкласса
NSObjectкак посреднический контроллер, нет никакой причины пройти через всю работу, требуемую сделать его один. Используйте вместо этого один из готовыхNSControllerобъекты разработаны для технологии привязки Какао; т.е. используйте экземплярNSObjectController,NSArrayController,NSUserDefaultsController, илиNSTreeController— или пользовательский подкласс одного из них бетонируетNSControllerподклассы.Однако, если приложение очень просто, и Вы чувствуете себя более удобными, пишущий, что код связующего звена должен был реализовать посредническое поведение с помощью выходов и целевого действия, не стесняйтесь использовать экземпляр пользовательского
NSObjectразделите на подклассы как посреднический контроллер. В пользовательскомNSObjectподкласс, можно также реализовать посреднический контроллер вNSControllerсмысл, с помощью кодирования значения ключа, наблюдения значения ключа и протоколов редактора.Несмотря на то, что можно объединить роли MVC в объекте, лучшая общая стратегия состоит в том, чтобы сохранить разделение между ролями. Это разделение улучшает возможность многократного использования объектов и расширяемость программы, в которой они используются. Если Вы собираетесь объединить роли MVC в классе, выберите преобладающую роль для того класса и затем (в целях обслуживания) категории использования в том же файле реализации для расширения класса, чтобы играть другие роли.
Цель хорошо разработанного приложения MVC должна состоять в том, чтобы использовать как можно больше объектов, которые являются (теоретически, по крайней мере) допускающие повторное использование. В частности объекты представления и объекты модели должны быть очень допускающими повторное использование. (Готовые посреднические объекты контроллера, конечно, являются допускающими повторное использование.) Специализированное поведение часто концентрируется как можно больше в объектах контроллера.
Несмотря на то, что возможно иметь представления, непосредственно наблюдают, что модели обнаруживают изменения в состоянии, лучше не сделать так. Объект представления должен всегда проходить через посреднический объект контроллера узнать об изменениях в объекте модели. Причина является двукратной:
Если Вы используете механизм привязки для имения объектов представления, непосредственно наблюдают свойства объектов модели, Вы обходите все преимущества это
NSControllerи его подклассы дают Ваше приложение: выбор и управление заполнителем, а также возможность фиксировать и отбросить изменения.Если Вы не используете механизм привязки, необходимо разделить существующий класс представления на подклассы для добавления возможности наблюдать уведомления изменения, отправленные объектом модели.
Стремитесь ограничить зависимость от кода в классах Вашего приложения. Чем больше зависимость, которую класс имеет на другом классе, тем менее допускающий повторное использование это. Определенные рекомендации варьируются ролями MVC этих двух включенных классов:
Класс представления не должен зависеть от класса модели (несмотря на то, что это может быть неизбежно с некоторыми пользовательскими представлениями).
Классу представления не придется зависеть от посреднического класса контроллера.
Класс модели ни от чего не должен зависеть кроме других классов модели.
Посреднический класс контроллера не должен зависеть от класса модели (несмотря на то, что, как представления, это может быть необходимо, если это - пользовательский класс контроллера).
Посреднический класс контроллера не должен зависеть выставленные для обозрения классы или от координирования классов контроллера.
Класс контроллера координирования зависит от классов всех ролевых типов MVC.
Если Какао предлагает архитектуру, решающую проблему программирования, и эта архитектура присваивает роли MVC объектам определенных типов, используйте ту архитектуру. Если Вы сделаете, будет намного проще соединить Ваш проект. Архитектура документа, например, включает шаблон проекта XCode, конфигурирующий
NSDocumentобъект (модельный контроллер на перо) как Владелец Файла.
Контроллер представления модели в какао (OS X)
Шаблон разработки Контроллера представления Модели является основным принципом многих механизмов Какао и технологий. Как следствие важность использования MVC в объектно-ориентированном проекте идет вне достижения большей возможности многократного использования и расширяемости для Ваших собственных приложений. Если Ваше приложение должно включить технологию Какао, которая основана на MVC, Ваше приложение будет работать лучше всего, если его проект также будет следовать за образцом MVC. Это должно быть относительно безболезненным для использования этих технологий, если приложение имеет хорошее разделение MVC, но потребуется больше усилия использовать такую технологию, если у Вас не будет хорошего разделения.
Какао в OS X включает следующую архитектуру, механизмы и технологии, основывающиеся на Контроллере представления Модели:
Архитектура документа. В этой архитектуре основанное на документе приложение состоит из объекта контроллера для целого приложения (
NSDocumentController), контроллер возражают для каждого окна документа (NSWindowController), и объект, комбинирующий контроллер и роли модели для каждого документа (NSDocument).Привязка. MVC является центральным к технологии привязки Какао. Конкретные подклассы краткого обзора
NSControllerобеспечьте готовый контроллер возражает, что можно сконфигурировать для установления привязки между объектами представления и должным образом разработанными объектами модели.Приложение scriptability. При разработке приложения для создания его scriptable важно не только, что это следует шаблону разработки MVC, но и что должным образом разработаны объекты модели приложения. Сценарии команд, которые состояние приложения доступа и поведение приложения запроса должны обычно отправляться в объекты контроллера или объекты модели.
Базовые Данные. Базовая платформа Данных управляет графиками объектов модели и гарантирует персистентность тех объектов путем сохранения их к (и получения их от) персистентное хранилище. Базовые Данные тесно интегрируются с технологией привязки Какао. MVC и шаблоны разработки объектного моделирования являются существенными детерминантами Базовой архитектуры Данных.
Отмена. В архитектуре отмены объекты модели еще раз играют центральную роль. Примитивные методы объектов модели (которые обычно являются его методами доступа) часто, где Вы реализуете отмену и восстанавливаете операции. Представление и объекты контроллера действия могут также быть вовлечены в эти операции; например, у Вас могли бы быть такие объекты, дают определенные заголовки отмене и восстанавливают пункты меню, или Вы могли бы сделать, чтобы они отменили выборы в текстовом представлении.