Имеет ли смысл отделять контроллеры представлений от представлений в iOS?

Question

Исходя из опыта веб-разработки, занимаясь в основном приложениями на основе MVC, я привык разделять компоненты моего кода на три группы файлов: контроллеры, модели и представления.

Но имеет ли смысл следовать той же методике в приложении для iOS, даже используя шаблон MVC?

UIViewController предоставляет вам представление по умолчанию, где вы можете добавить остальные подпредставления (UILabel, UIButton...) и иметь немедленный доступ к ним. И язык тот же, это не то же самое, что иметь дело с HTML/CSS и чем-то еще.

Но я сталкивался с некоторыми приложениями для iOS, где UIView находится в подклассе и поддерживается в отдельном файле, даже если он будет использоваться только в UIViewController, Таким образом, вы должны кодировать пользовательские методы доступа для работы с внутренними подпредставлениями.

Я не вижу необходимости делать это, если, конечно, вы не используете то же самое UIView в нескольких местах или делать заказные рисунки.

Answer 1

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

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

Итак, вы спросили:

Я не вижу необходимости делать это [создание подкласса UIView], если, конечно, вы не используете один и тот же UIView в нескольких местах или не делаете собственный рисунок.

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

1. У меня было представление календаря в приложении, и контроллер представления становился громоздким, управлял всеми ячейками для различных дней в месяце и т. Д. UIViewМне удалось абстрагировать уродливые детали всех подпредставлений, составленных с помощью календаря. Я разделил на подклассы не только основное представление "месяц", но и представление "день" в представлении "месяц". Нет повторного использования как таковое. Нет пользовательского рисунка. Но это было, очевидно, правильно. Код бесконечно более разборчивый.

2. Я всё подкласс UITableViewCell для моих просмотров таблицы. В моих первых проектах у меня были бы контроллеры табличного представления cellForRowAtIndexPath сделать всю сложную композицию и расположение этой клетки. Мой код намного легче следовать сейчас, когда я регулярно делю UITableViewCell в любой ситуации, что я не использую один из стандартных типов клеток.

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

В итоге, хотя вам не нужно все время подклассировать представления, я лично считаю, что многие разработчики виновны в том, что не смогли подклассировать представления (или модели), когда это необходимо. Они не должны делать это из-за какого-то фанатичного желания соответствовать MVC, а должны спрашивать себя, будет ли их код легче читать и поддерживать, если они подклассируют представление или модель соответствующим образом.

Answer 2

Обычно я бы UIViewController <=> SingletonManager <=> Фактический источник данных. Я предпочитаю держать вещи хорошо разделенными. Если мне случится иметь обычай UIViewгде я делаю свой собственный чертеж, у меня будет другой файл для этого, потому что это имеет смысл. Даже если я использую только в одном месте (вы никогда не знаете, что вам понадобится завтра, и вам может понадобиться это где-то еще). Также не забывайте, что на самом деле MVC хорошо разделен в iOS:

• NIBS / StoryBoard / Пользовательский рисунок
• UIViewControllers
• Источник данных

Answer 3

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

Теперь, если вы спрашиваете об использовании пера или подкласса, это то же самое, что выбирать между составом и наследованием.

Если вам нужно иметь специальное представление, создайте подкласс UIView, но если вы хотите иметь представление с элементами управления в качестве подпредставлений, используйте композицию, и для построения представления проще использовать Interface Builder.

Единственная причина, по которой я вижу наличие подкласса UIView только для подвидов, - для лучшей инкапсуляции, но поскольку ваш контроллер написан специально для представления, нет необходимости иметь эту инкапсуляцию.

Answer 4

Это может быть хорошим примером, поскольку вы имеете дело с разницей между тем же приложением на iPhone и iOS. То, что может быть DetailViewController на iPad, может быть UINavigationController на iPhone.

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