Архитектура iOS MVC - отдельный вид, отличный от вида контроллера представления - PullRequest
Новая
       50

Архитектура iOS MVC - отдельный вид, отличный от вида контроллера представления

3 голосов
/ 15 марта 2012

Обзор

  • Я делаю проект iOS с использованием архитектуры MVC.Простите за мое невежество, я просто растерялся, я ищу хороший дизайн.
  • Представление, которое я планирую использовать, будет иметь несколько кнопок, некоторые метки и текстовые поля.Моему представлению не нужна какая-либо пользовательская реализация drawRect.
  • Вся моя логика относительно того, что нужно делать, когда нажимается кнопка или происходит событие, находится в моем контроллере представления

У меня есть пара сомнений:

  1. для приведенного выше сценария, все же лучше (хорошая практика) создать отдельное представление (представление, отличное от представления контроллера)Посмотреть) ?Если да, то почему?

  2. Кроме рисования и отображения представления (в моем проекте у меня его мало), что еще должен содержать код реализации представления?

  3. Я хотел бы отключить набор кнопок, когда пользователь касается текстового поля и клавиатура появляется.

    a) Поэтому я должен поместить эту логику отключения некоторых кнопок вРеализация отдельного представления (представление, созданное в вопросе 1)?

    b) Могу ли я создать родительские представления (представление, созданное в вопросе 1) для кнопок (которые являются подпредставлениями), чтобы отключить некоторые кнопки?Я не могу этого сделать.Или я должен использовать метод subviews и перебрать нужную кнопку?

Мое понимание

  1. Модель содержит данные

  2. Представление отвечает за отображение и не должно содержать бизнес-логики.

  3. Контроллер представления является единственным, который взаимодействует междуМодель и представление и содержит бизнес-логику

Ответы [ 2 ]

4 голосов
/ 15 марта 2012

  1. Нет необходимости создавать отдельное представление - представление контроллера представления (обычно просто обычный UIView), безусловно, может содержать ваши кнопки и текстовые поля. Если вы хотите поместить некоторые из них в отдельный контейнер (возможно, чтобы вы могли переместить их как группу), вы можете использовать для этого простой старый UIView.

  2. Представления являются респондентами, поэтому подклассы UIView могут переопределять методы обработки касания, если вы хотите выполнить какую-либо специальную обработку касания.

  3. a) Обычно код, управляющий представлениями (например, отключение кнопок), помещается в контроллер представления. б) Опять же, вы обычно помещаете выходы для ваших кнопок в контроллер вида.

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

0 голосов
/ 15 марта 2012

Q1. для приведенного выше сценария все же лучше (хорошая практика) создать отдельное представление (представление, отличное от представления контроллера представления)? Если так, то почему?

Если вы создаете свое представление с помощью Interface Builder, я думаю, что это отдельное представление. ;) Но если вы попытаетесь создать иерархию представлений программно, не используя n / xib, вы можете поместить все макеты представлений в метод loadView и заполнить данные в viewDidLoad, что и делает View-Controller. Кроме того, вы можете создать класс UIView для реализации макета представления, как n / xib, но программно.

Как сказал DOC,

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

... Контроллер вида - это контроллер, который в основном относится к слою вида. «Владеет» интерфейсом (представлениями); его основные обязанности состоят в том, чтобы управлять интерфейсом и связываться с моделью. Методы действия, связанные с данными, отображаемыми в представлении, обычно реализуются в контроллере представления. NSWindowController объект (также часть архитектуры документа) является примером контроллера представления. ...

MVC в Какао немного отличается от того, что вы знаете. Вы можете сослаться на официальный документ ЗДЕСЬ .

Q2. Кроме рисования и отображения представления (в моем проекте его немного), что еще должен содержать код реализации представления?

Вы можете настроить вид, например, установить цвет текста или стиль шрифта для своей кнопки и т. Д.

Q3.a. Поэтому я должен поместить эту логику отключения некоторых кнопок в реализацию отдельного представления (представление, созданное в вопросе 1)

Лучше поместить логику в контроллер (или view-controller), как предпочитают MVC.

Q3.b. Могу ли я создать выходы для кнопок (которые являются подпредставлениями), чтобы отключить некоторые кнопки из моего родительского представления (представление, созданное в вопросе 1)? Я не могу этого сделать. Или я должен использовать метод subviews и перебрать нужную кнопку?

Вы можете установить тег (setTag:) для своих кнопок и получить нужный вам. Но имейте в виду, во-первых, вам нужно разрешить показанную кнопку родителю.

...