Какой код должен быть в файле класса uiviewcontroller при следовании шаблону проектирования mvc? - swift4

Я пытаюсь понять, как быстро реализовать MVC. Вот мой сценарий:

У меня есть страница регистрации с 9 UITextFields, и все они создаются программно и поэтому программно привязаны к представлению. Как вы понимаете, в файле класса SignupViewController будет много повторяющегося кода.

Является ли соглашение при соблюдении MVC сохранять настройки этих текстовых полей в файле SignupViewController, или у вас должен быть отдельный файл, такой как SignupView, который содержит весь код настройки текстовых полей?

0
0
672
4
Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

Ответ на ваш вопрос заключается в том, что это не имеет ничего общего с MVC.

Как разработчики iOS / Mac, мы используем конструктор интерфейсов и auto_layout для достижения большей части UI @ IBOUtlet / @IBAction. Это сторона V MVC.

Как правило, если у вас есть данные, база данных, json или любые другие форматы, вам необходимо смоделировать их и обработать логику. Это'M MVC.

Сторона C (Контроллер) в MVC - это своего рода клей между M и V. В большинстве случаев на мобильных устройствах вы можете думать, что контроллеры - это все, что вам нужно.

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

В вашем случае 9 UITextfields в идеале должны быть помещены в подработку V. Пожалуйста, не пишите для них код, если нет лучшего способа сделать это.

Ответ принят как подходящий

Несмотря на то, что в UIViewController есть слово «контроллер», я считаю, что большинство разработчиков iOS в наши дни назначают UIViewController стороне «View» MVC. UIViewController в основном специфичен только для определенного представления, а также может управлять своими вложенными представлениями (пока это не станет слишком беспорядочным и не будет добавлено представление контейнера, позволяющее использовать вложенный UIViewController).

В MVC на iOS контроллер представления может легко стать загрязненным бизнес-логикой, управлением моделями и т. д., Поэтому многие люди в шутку называют «MVC» в iOS «Контроллером массового представления». Чтобы бороться с этим, рассмотрите возможность использования вместо этого архитектуры MVVM, которая не только сохраняет небольшие VC, но и перемещает бизнес-логику в отдельный «sidecar», связанный с этим ViewController, который называется ViewModel. Это позволяет проводить модульное тестирование бизнес-логики без использования какого-либо пользовательского интерфейса, что делает тестирование более надежным и простым для чтения и сопровождения. С учетом сказанного, создание этих 9 элементов управления по-прежнему будет принадлежать ViewController.

Что касается программного добавления UITextFields к вашему представлению vs viewController, если это должно быть сделано только для этой единственной сцены, я бы вставил его в viewController. Если вы ожидаете, что захотите повторно использовать их набор в других сценах, тогда будет лучше создать настраиваемый вид или элемент управления, содержащий их, как это обычно делается для настраиваемых ячеек таблицы.

Наконец, подумайте о том, чтобы просто использовать перо или раскадровку для макета вашей сцены. Apple предоставила столько возможностей для компоновки и поддержки сцен с помощью перьев и раскадровок, что вы действительно упускаете из виду, чтобы пойти по программному пути. Я очень редко принимаю сторону программного подхода. Предупреждения об автоматической компоновке в InterfaceBuilder сами по себе стоят для меня золота, и поскольку Apple продолжает поднимать планку и изменять правила компоновки, я не могу себе представить, чтобы не отставать от программных средств, когда я не могу позволить себе тестировать каждое устройство и версию iOS. комбинация. И да, можно сделать MVVM с внедрением зависимостей и раскадровкой. Я делаю это ежедневно.

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

чтобы минимизировать файл, вы можете создать расширение ViewController в отдельном файле, чтобы содержать весь этот код.

поэтому для RegistrationViewController вы должны создать новый файл с именем RegistrationViewController + SetupUI.swift.

import UIKit

extension SignupViewController {
    // add your setup methods here

    // as just an FYI you can call the methods you create from your
    // SignupViewController file just like you would any other method.
}

вы можете узнать больше о расширениях здесь.

Прочитав о хороших практиках написания поддерживаемого и читаемого кода, вы должны полностью разработать дизайн в конструкторе интерфейсов. Если вы хорошо понимаете ограничения, вам не нужно писать код для настройки дизайна в вашем контроллере представления. Файл ViewController.swift не следует использовать для обработки данных или для настройки пользовательского интерфейса. Он должен просто отвечать за отображение и обновление значений, которые извлекаются и обрабатываются в отдельном файле ViewControllerDatasource.swift. Подводя итог, контроллер представления не имеет какой-либо реализованной логики, он просто обрабатывает данные шоу и обновления дизайна (не настройку). Надеюсь, я помог тебе с твоим вопросом.

Спасибо! Итак, если у меня есть UITableViewController в моем ViewController, будет ли код, который разбивает данные из базы данных на страницы для заполнения tableview, в другом файле. Будет ли этот код разбивки на страницы, который заполняет tableview, частью «контроллера»?

cabyambo 15.09.2018 05:35

Это будет частью источника данных. Очевидно, панель поиска находится в файле ViewController. Но фильтр ваших данных, выборка и т. д. Будут в файле Datasource. Например, для представления таблицы в вашем ViewController функция, которая возвращает количество строк, должна быть «return datasource.numberOfTableElements ()» То же самое с разбивкой на страницы, объектом по индексу и т. д.

savvas.pyth 17.09.2018 01:01

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

savvas.pyth 17.09.2018 01:10

Другие вопросы по теме