MVC Выкройка: Где относится работа по форматированию/обработке? (Objective-C)

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Вот обсуждение шаблона Visitor в Objective-C/какао: http://www.cocoadev.com/index.pl?VisitorPattern

Вот (старая !!!) статья от Dr.Dobbs о шаблоне посетителя в объекте-c: http://www.drdobbs.com/184410252

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

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