Введение в MVC для начинающих разработчиков

В этой статье рассмотрим минимум информации, которую нужно знать о парадигме Model-View-Controller (MVC), которая широко используется при разработке приложений под iOS  и под MacOS.

View — отображает данные на дисплее.
Model (данные) — «мозг» программы, то что она делает. Сюда входят алгоритмы программы, обработка данных и т.п.
Controller — обеспечивает связь между моделью (Model) и представлением (View).

Способы реализации связей, которые используются в iOS и MacOS 10.

Самые распространенные из них это:

  • Target -Action
  • Notification (Уведомление)
  • Delegation(Делегирование)

Target-Action нацелен на ослабление связей между элементами программы, на использование этих элементов без необходимости их сабклассинга.


-(void)addTarget:(id)target action:(SEL)action forControlEvents … ;

Notifications -Широковещательные каналы для важных сообщений

Тип  связей Notifications(уведомление) зачастую используется для оповещения.

Например, есть класс клавиатуры в iPhone iOS, и клавиатура собирается появиться. Вы не можете контролировать этот процесс, он просто происходит. Клавиатура появляется на экране, но она может также разослать «новость» о том, что она сейчас появиться на экране. Вы можете это использовать для того, чтобы, например, изменить размеры каких-то ваших компонентов на экране, подогнать их под уменьшенный размер экрана или еще инициализировать какие-то объекты, которые будут проверять вводимый текст с помощью клавиатуры  и т.д. Этот тип связи  один — много, «один говорит, много слушают».

Следующая связь Delegation (делегирование)

Повторное использование без сабклассинга.

Например, когда пользователь нажимает кнопку return на клавиатуре, текстовое поле может послать сообщение своему делегату и спросить у него «мне завершить редактирование?». Делегат отвечает «Да» и тогда поле убирает клавиатуру. Эта связь произошла благодаря методике делегирования. Многие классы реализуют делегирование для выполнения работ схожих с данной: UITextField, UIApplication, UITableView, UIWebView, UIScrollView и т.д. Делегирование очень легко обнаружить. Если вы видите в описании класса, в документации или же в коде методы со словами will/did/should, это означает, что на 99% вы имеете дело с делегированием.

Например, UIApplication может сказать: «Я собираюсь завершить работу». Это сообщение посылается тогда, когда приложение закрывается и будет закрыто через некоторое время. Может быть также вызван метод UIApplication, если вы его реализовали в вашем классе AppController.

-(void)applicationWillTerminate:(UIApplication *)application.
UIScrollView хочет сказать «Я изменил масштаб»
-(void)scrollViewDidZomm:(UIScrollView *)scrolView;
UITextField хочет спросит «Мне очистить свое содержимое?»
-(BOOL)textFieldShouldClear:(UITextField *)textField;

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

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

А теперь рассмотрим «коробки» в этой диаграмме Model-View-Controller.
Что такое Model? Традиционное определение — это данные программы. Но оно также включает в себя алгоритмы и работу с сетью, если она ведется в рамках вашего приложения. Это то, что ваше приложение делает,  что отличает ваше приложение от других и,  что у нее происходит «под капотом»; это мозг вашей программы.
View — это то, с чем работает пользователь, то что отображается у него на экране. Он служит для отображения данных,  перехвата событий,  визуального контакта с пользователем, но не предназначен для обработки данных. Это то, что делает вашу программу красивой, это представление данных.
Controller — это то, что координирует действия модели и представления, это реализация таких способов связи, как делегация и уведомление и т.д. Это также прослушка уведомлений, различные работы, которые не входят в модель. Например, это валидация веденных пользователем данных, т.е. проверка  их на правильность и т.д.

Важно знать, что «представления» не владеют информацией. Они лишь отображают ее.
Не смотря на то, что у текстового поля есть свойство text, где храниться введенный текст, важно  его скопировать в  Model и хранить его там. Поскольку  «представление» может исчезнуть, экран может измениться, и текстовое поле может стереться из памяти, что приведет в данном случаи к потери информации.  Важно хранить информацию в модели, а «представлениям» давать только отображать ее.
Также стоит сказать, что приложение целесообразно сделать стандартным с точки зрения пользовательского интерфейса, чтобы пользователи знали, как оно работает, только лишь взглянув на него. Так что при разработке интерфейсов и «представлений» опирайтесь на объекты и классы, которые вам предоставляет iPhone OS, точнее говоря framework UIKit. Framework UIKit это богатый набор контролов и виджетов,  которые существенно облегчат вам жизнь и сделают работу с вашим приложением интуитивно понятной.

Посмотрим на управление объектами с точки зрения MVC.

Это простые правила, которые нужно знать, соблюдение которых сделает вашу работу более эффективной:

1. Если объект создает другой объект, то он ответственен за его уничтожение.
2 «Дети» не живут дольше родителей.
Рассмотрим эти два правила более детально.

При удалении из памяти модели, удаляется и контроллер. Контроллер  это «дитя» модели. Модель выступает родителем для контроллера.

3 Model никогда не владеет View. View никогда не владеет Model или Controller.

Например, у нас есть модель, которая создает контроллер и владеет им. В свою очередь Controller создает View и владеет им. Внутри View могут быть различные subView, т.е. кнопки, scrollBar, progressBar, таблицы и т.д. Это правильный способ управления объектами. Если мы удалили  Model из памяти, то Controller автоматически уничтожится. Так как View является «сыном» контроллера, то он тоже автоматически уничтожится, уничтожив вместе с собой все свои subView, т.е.  таблицы и кнопки.  Нельзя чтобы Controller ссылался на Model, т.е. владел ею; нельзя чтобы View владела Controller, иначе, если бы View владела, например, контроллером, то при уничтожении модели, контроллер бы не уничтожился и ссылка на контроллер просто бы потерялась.

5. «Объекты — фабрики» передают право владения.
Что такое «объекты — фабрики»? Это классы, которые позволяют создавать объекты своего класса.
На пример, есть класс UIButton при использовании которого с помощью метода buttonWithType вы можете создать кнопку Button.
UIButton *button = [UIButton buttonWithType:UIButtonTypeRoundedRect];
[button retain]; или [view addSubview:button];
«Фабрика» создала объект и надо решить, что с ним делать: или запомнить ссылку на объект, потом его уничтожив, посредством вызова метода release или добавить кнопку на view методом subView и забыть про кнопку, т.к. при уничтожении View уничтожаются все его subView.

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

Вы можете оставить комментарий, или ссылку на Ваш сайт.

2 комментариев к записи “Введение в MVC для начинающих разработчиков”

  1. Ну я бы поспорил с утверждением:

    «При удалении из памяти модели удаляется и контроллер. Контроллер это «дитя» модели. Модель выступает родителем для контроллера.»

    Обычно как раз сначала создаётся контроллер который получает модель (часть её) в качестве параметра или создаёт её по мере необходимости. В этом смысле контроллер контролирует модель и view.

Оставить комментарий