3

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

Что я пытаюсь сделать

Что я делаю это довольно просто: у меня есть некоторые пользовательские CALayer подклассы, которые представляют собой интерактивный элемент пользовательского интерфейса. Они разбиты на несколько уровней, так как некоторые части пользовательского интерфейса являются статическими, поэтому я не хотел, чтобы они ненужно перерисовывали эти статические элементы. В настоящее время слои добавляются как подслои в части инициализации класса CustomView, который является подклассом UIView.

Существует в настоящее время не соответствующий CustomViewController класс, подкласс UIViewController, потому что, когда я использую CustomView, он содержится в UITableViewCell или части общего UIViewController с другими видами в ней, так что я чувствовал другое UIViewController для каждого экземпляра CustomView будет излишним.

Также важно, чтобы единственная операция, которую я выполняю внутри класса UIView, я отвечаю на события касания и отправляет сенсорную информацию на подуровни, чтобы пользовательский интерфейс мог соответствующим образом обновлять внешний вид. Я не переопределяю метод drawRect или что-то в этом роде.

Вопрос

В принципе, я пытаюсь выяснить, является ли я должен либо:

Вариант 1:

Избавиться от CustomView класса, создать CustomViewController класс который является подклассом UIViewController, и просто добавьте объекты CALayer в качестве подслоев CustomViewController, встроенных в view.

или

Вариант 2:

Мои мысли о UIViewController подкласс является излишним является правильным, так что я должен оставить его так, как он у меня и есть CustomView класс с CALayer объектами внутри из Это.

Я был бы очень признателен за любые советы по этому вопросу.

+0

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

+0

Спасибо за быстрый ответ. Приятно слышать, что я не ухожу в режиме, отличном от 'UIViewController', который он реализует в настоящее время. –

ответ

0

Я думаю, что с точки зрения MVC код, который вы описываете (вариант № 2), хорошо написан и поддерживает очень четкую границу ответственности. Вы не пишете какой-либо код, который не имеет никакого отношения к самому слою представления в этом классе, что отлично. Я думаю, что в этом случае нет необходимости в отдельном подклассе UIViewController для управления этими экземплярами, потому что, как вы сказали, они обрабатывают свои собственные события касания и видимые слои (в точности их ответственность).

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

Учитывая, что вы представили ситуацию, я считаю, что поддержание экземпляра CALayer в этом подклассе UIView («CustomView») - правильный путь.

+0

Спасибо за ответ! Хотя он еще не реализован, элемент пользовательского интерфейса будет анимировать на основе информации, которая будет сохранена/загружена из iCloud. Считаете ли вы, что, поскольку я буду использовать iCloud, я должен реализовать метод 'UIViewController', описанный в опции 1? Альтернативой варианту 1 было бы сделать что-то вроде 'CustomView * cv = [[CustomView alloc] initWithData: elementData];', где elementData уже загружен 'UITableViewController' и т. Д. Однако эта альтернатива, вероятно, нарушает MVC с момента смешивания взгляда с моделью. –

+0

На мой взгляд, подкласс UIView не должен иметь метод initWithData - это, без сомнения, противоречие с парадигмой MVC. Если данные должны быть загружены из iCloud, может быть место для рассмотрения чего-то более сложного. С другой стороны, я вижу много подклассов UIImageView, которые обрабатывают кеш, например, кеш имеет отношение к хранению (никоим образом не связанному с элементами представления). В этом вопросе есть определенные «правильные» и «неправильные», хотя важно поддерживать понятный код. – Stavash

+0

После того, как я опубликовал это, я подумал, что вместо того, чтобы предоставить элементу пользовательского интерфейса фактические данные, я мог бы просто иметь метод, который устанавливает произвольное целое число, в котором должен быть оживлен элемент. Например, при настройке 'UITableViewCell' я мог бы сделать следующее:' [[CustomView alloc] initWithValue: data.integerValue]; 'где data - данные iCloud, которые были загружены' UITableViewController' и 'integerProperty' это значение, которое непосредственно соответствует появлению элемента пользовательского интерфейса. Я думаю, что это сохранит целостность парадигмы MVC. –

Смежные вопросы