Ловушка MVC: Ошибки и решения

Л

Model View Controller (MVC), о котором мы не раз писали является фундаментальным шаблоном проектирования для приложений iOS и OS X. Идея этого паттерна в том, что каждый из трех слоев имеет четкую и точную роль, что приводит к большому количеству переиспользования кода и меньшему количеству ошибок. Тем не менее, в разработке под iOS существует грубая тенденция — нагружать контроллер больше чем нужно — это ловушка MVC. В этой статье мы обсудим несколько способов обхода этой ловушки.

Ловушка MVC: Теория

Давайте посмотрим на три слоя шаблона MVC:

  1. Слой модели (Model) — содержит все данные и всю логику, относящуюся к данным — так называемую business-логику. Тем не менее модель не знает ничего о представлении этих данных. Это означает, что модель не может быть использована без каких либо изменений в приложении. Модель может взаимодействовать со слоем контроллера. Но со слоем представления она не контактирует.
  2. Слой представления (View) — содержит все объекты, которые пользователь может видеть. Это почти всегда UIView или его подкласс. Слой взаимодействует с контроллером как и модель, но с моделью его ничего не связывает.
  3. Слой контроллера (Controller) — поддерживает связь между слоями модели и представления.

Если эти принципы соблюдаются, ваше приложение будет хорошо структурировано.

Ловушка MVC: Реальность

К сожалению, на данный момент все выглядит немного иначе. Существует тенденция нагромождать контроллер тоннами кода. Например, если создается калькулятор, то вроде как очевидно, что всю его логику нужно занести в контроллер! Но это только на первый взгляд так. Новички в MVC чувствуют себя комфортнее именно так. Но в конце концов это плохое решение. Такой подход создаст проблемы в портировании  и так же приведет к избыточному коду.

С другой стороны, если у вас есть крупное приложение с хорошей архитектурой, то у вас скорее всего будет много классов в проекте. И если структура файлов в проекте продумана, то это не должно быть проблемой.

Ловушка MVC: Решения

От ловушки MVC не существует панацеи. Но есть много мелких вещей, которые вам помогут. Суммируя эти решения, вы сделаете архитектуру приложения в разы лучше.

Планирование

Одной из главных причин плохой архитектуры MVC является недостаточно отточенный проект. Перед тем, как приступить к созданию проекта Xcode, вы должны иметь представление об архитектуре приложения. Большинству людей это не нравится, но крайне желательно создавать диаграмму UML. Конечно, это не много изменит в процессе программирования, но это поможет получить приблизительное представление об архитектуре приложения, что позволит осознать, какие компоненты принадлежат модели, представлению и контроллеру.

Аутсорсинг ваших делегатов, если уместно

Делегаты являются очень важным элементом в хорошей архитектуре приложений, потому что использование делегатов приводит к меньшему количеству наследований  и меньшему количеству связей. Тем не менее это сильно увеличивает код, особенно если ViewController, например, имеет несколько делегатов: UITableViewControllerDelegate, UIScrollViewDelegate, UIAlertViewDelegate и т.д. Есть один важный шаг, который значительно улучшит структуру кода — аутсорсинг, вынесение всех делегатов в отдельный класс. О том, как это делается вы можете прочесть одной из предыдущих наших статей.

Создание объектов логики

Это очень важный шаг! Например, если вы программируете калькулятор, то вы должны создать отдельный объект под названием CalculatorLogic. Этот объект должен делать все что связано с расчетами. ViewController просто передает этому объекту введенную информацию, и CalculatorLogic сообщает контроллеру о новых результатах, а контроллер информирует представление о новой информации к отображению.

Создание вспомогательных объектов

Это похоже на предыдущий пункт. Есть несколько задач, которые не являются чистой бизнес-логикой, но по прежнему принадлежат слою модели. К таким задачам относится нечто вспомогательное, опорное. Например, это может быть связь с бекендом. Эти сетевые вызовы не должны непосредственно принадлежать логике ViewController. В место этого, вы можете создать объект NetworkCommunication, который будет иметь функцию getAllProducts и ViewController просто будет вызывать эту функцию. Это большое преимущество — иметь одну функцию для выполнения конкретной задачи. И эта функция может быть вызвана из других ViewController. То есть с таким подходом, имея 5 ViewController-ов, у вас будет всего одна точка соединения с сетью, а не 5. Другой хороший пример вспомогательного объекта — объект для соединения с базой данных.

Подумайте о вашем коде

Как и в иных областях — первый блин обычно комом. Если вы выполнили конкретную задачу, не спешите идти дальше. Тщательно проанализируйте написанный код и постарайтесь сделать его еще лучше. Такой мини-рефакторинг занимает мало времени, но резко увеличивает качество кода.

Взгляд наружу

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

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

 

Поддержите ресурс blog.justDev:

Сведения об авторе

Игорь Малеваный

1 комментарий

  • Отличная статья, я тоже на это раньше не обращал внимания
    Сейчас изучаю арх паттерн MVP
    Для меня это хороший MVC и считаю что по нему должны идти все туторы
    Единственное что меня смутило в статье это про бизнес логику в модели
    Насколько я знаю, модель в первую очередь просто набор полей, описуюших некий обект

Instagram

Поддержите ресурс blog.justDev:

Свежие записи

Рубрики