MVC в Какао Touch

Question

У меня проблемы с пониманием, правильно ли я реализую шаблон MVC в приложении для iPhone.В моем приложении есть виды, контроллеры и модели.Контроллеры представлений управляют интерфейсами, переходят к другим контроллерам представлений, устанавливают переменные для других контроллеров и моделей представлений и взаимодействуют с моделями.Но так ли я правильно следую шаблону MVC?Разве я не скучаю по модельному контроллеру?

Еще один вопрос: у меня есть пользовательская модель, к которой мне нужно иметь доступ практически во всех моделях и некоторых контроллерах.Было бы правильно определить его как переменную в appDelegate?Я все время читаю, что это плохая практика, но я не понимаю, почему в этом случае.

Answer 1

Глобальные объекты

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

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

Appdelegate - это Singleton, так что это обсуждение связано: Что такого плохого в синглетах? и Singletons: хороший дизайн или костыль? .

MVC

Apple говорит об этом в Основные сведения о ядре какао и Руководство по основам какао .

Можно объединить роли MVC, сыгранные объект, делая объект, для пример, выполняйте оба контроллера и просматривать роли - в этом случае это будет называться контроллером представления. в таким же образом, вы также можете иметь модель-контроллер объектов. Для некоторых приложения, сочетающие роли, такие как это приемлемый дизайн.

Достаточно ли сложен ваш дизайн, чтобы требовать модель контроллера? Каково бы ни было ваше решение, страдания от последствий многому вас научат. :)

Answer 2

Шаблон проектирования, в котором модель (любые данные в вашей программе), представление (то, что видит пользователь) и контроллер (слой, который обрабатывает все взаимодействия между представлением и моделью) разделены таким образом, чтоизменение компонента вида или модели вашей программы не влияет друг на друга.

Цель:

Цель состоит в том, чтобы позже вам, возможно, потребовалось изменить представление ваших программ, и, программируя вещи в этом вопросе, вам не придется изменять модель ваших программ.Скажем, например, Apple выпускает iPad, для которого представление запрограммировано несколько иначе, чем на iPhone, но вы хотели бы

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

Ну, не волнуйтесь .. Я видел повсюду аргументы относительно того, какие компоненты должны быть классифицированы в модели, представлении или контроллере, и я даже видел выполненного "гуруАвторы «путаются, когда объясняют, что и где, просто имейте в виду, что ключевая идея здесь заключается в том, что вы можете изменить одну из этих ключевых областей, не разрушая другую ключевую область вашей программы, и оставить все как есть подражателям, которым нравитсяспорить о том, что именно то, что подходит, что сокращение и MVC часто является их целью.