Практика MVC относительно добавления целей в UIButton on View - PullRequest
1 голос
/ 03 марта 2012

У меня есть вопрос, касающийся лучших практик при добавлении целей в UIButton в пользовательском представлении. В настоящее время я создаю свой UIButton в методе загрузки моего вида и назначаю мой вид в качестве кнопки назначения. Мой взгляд заключается в обработке логики при нажатии кнопки, и мне приходит в голову, что это нехорошо MVC.

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

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

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

Наконец, я могу создавать и добавлять цели для всех моих кнопок в контроллере и передавать их в представление при инициализации, но это, похоже, также нарушает роли MVC.

Кажется, что это обычный сценарий, считается ли какая-либо из этих практик стандартной или есть лучшее решение?

Ответы [ 2 ]

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

Мое личное убеждение в том, что в Какао пользовательские представления могут иметь логику и состояние, необходимые для их работы, но они должны полностью инкапсулировать логику и состояние. То есть вы должны предоставить интерфейс для подпредставлений, но не сами подпредставления. Вы должны предоставлять любые частные свойства или подпредставления через комбинацию делегатов и свойств, а также через настраиваемые действия.

С учетом вышесказанного, учитывая, что вы не указали конкретную информацию о назначении своего пользовательского представления, трудно предоставить информацию о наилучшем подходе.

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

Целесообразно ориентироваться на вид, которому принадлежат кнопки. Таким образом, если вам нужно выполнить какие-либо манипуляции с представлениями (включить / отключить, выделить, всплывающее окно и т. Д.), Вы окажетесь в нужном месте. Кроме того, только представление будет знать, что это за кнопка, так что в своем действии, если вы хотите проверить, что такое sender, вы можете сделать это. Но то, что ваш контроллер знает о каждой отдельной кнопке, кажется более вопиющим нарушением MVC.

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

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

Звучит так, как будто у тебя все хорошо.

PS Это глупо enter image description here

...