Шаблон MVC: Куда относится форматирование / тип обработки?(Objective-C)

Question

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

У меня есть пользовательский класс Model, который имеет многочисленные и разнообразные свойства (NSString, NSDate, NSNumber и т. Д.). У меня есть необходимость сериализации свойств для передачи. Иногда, когда эти данные обрабатываются для сериализации, могут возникнуть вопросы, на которые пользователь должен будет ответить (UIAlertView и т. Д.)

Не вдаваясь в подробности, где этот код принадлежит?

• Часть меня говорит: Модель , потому что речь идет о постоянстве данных - в некотором смысле.
• Часть меня говорит Представление , потому что это еще одна интерпретация базовых данных (без каламбура), содержащихся в модели. И пользователю придется взаимодействовать с диалогами при обработке данных
• Часть меня говорит: Контроллер , потому что он управляет преобразованием данных между моделью и представлением.

Это комбинация всех трех? Если да, то как будет обрабатываться связь между классами при обработке данных? NSNotifications? Прямые вызовы методов?

Answer 1

Это может быть то, что вы хотите использовать шаблон Visitor для - http://en.wikipedia.org/wiki/Visitor_pattern - потому что вы можете в конечном итоге использовать различные виды сериализации для разных вещей, и вы можете иметь различные классы посетителей, а чем много особых случаев в коде модели.

Вот обсуждение шаблона посетителя в target-c / cocoa: http://www.cocoadev.com/index.pl?VisitorPattern

Вот (старая !!!) статья доктора Доббса о структуре посетителей в target-c: http://www.drdobbs.com/184410252

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

Зачастую используемый вами код передачи / веб-службы (или любой другой) будет иметь собственный обработчик для этих данных, например ObjectiveResource добавляет обработчик сериализации и десериализации, который работает как расширение NSObject. это позволяет ему выполнять большую часть этих вещей прозрачно, и вы можете изучить этот код (особенно часть ObjectiveSupport), если вы пытаетесь сделать это более обобщенно.

Answer 2

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

Answer 3

Я бы сказал в модели.

Вызов для сериализации данных будет сделан контроллером. Если данные не могут быть сериализованы, то модель должна вернуть ошибку, которую затем должен обработать контроллер.

Answer 4

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

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

Виды могут быть размещены в Интерфейсном Разработчике или созданы в коде и / или могут быть разделены на подклассы для пользовательского чертежа, но они не должны иметь логику приложения и не будут взаимодействовать напрямую с моделью.