RESTful iPhone-клиент и иерархия моделей

Question

Мне любопытно, какую стратегию использует большинство из вас для создания надежных клиентов RESTful для iPhone с учетом иерархии моделей. Под иерархиями моделей я подразумеваю, что у меня есть REST-сервер, в котором несколько ресурсов связаны друг с другом. Например, предположим, в гипотетических целях у меня есть REST-сервер, который выкладывает информацию о школе. Если я хочу захватить всех учеников в определенном классе, мне сначала нужно запросить информацию о школе на сервере REST, затем мне нужно запросить у сервера информацию обо всех классах, которые должна предложить школа, затем последующий запрос для всех студентов в определенном классе. В конце концов, клиент вводит 3 уникальных дерева XML. В этот момент большинство из вас, ребята, пишут свои собственные алгоритмы для построения окончательного дерева, которое в конечном итоге станет вашим источником данных? Разве вы не агрегируете деревья XML в этом отношении и вместо этого используете другой подход?

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

Спасибо за понимание.

Answer 1

Существует проект под названием IPhone on Rails , в котором они создали реализацию Objective-C ActiveResource . У меня еще не было возможности поиграть с ним, но, возможно, стоит попробовать.

Answer 2

То, как вы решите хранить данные управления вашей модели на iPhone, вероятно, зависит от того, сколько XML-данных, с которыми вы работаете, может варьироваться, и насколько раздутыми они могут стать.

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

Но для всего, что немного сложнее, я предпочитаю переводить представления XML в формат, который наиболее легко манипулируется моим кодом Objective-C. Рассмотрим, например, возможность расширения вашего приложения за один день для поддержки других веб-сервисов, которые предоставляют аналогичные данные, но в виде данных в формате JSON или SOAP. Теперь вы начинаете сталкиваться с головными болями при обслуживании трех различных типов моделей в вашем приложении, когда было бы предпочтительнее поддерживать только одну.

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

Daniel

Answer 3

В моем собственном случае я использовал оболочки вокруг ASIHTTPRequest для создания запросов RESTful. Я обрабатывал результаты с помощью libxml2 , анализируемого непосредственно в объектах модели, отображаемых в пользовательском интерфейсе.

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

Answer 4

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

Это очень сложная проблема, если у вас нет стандартизированной системы для сериализации всех ваших объектов, возвращаемых с сервера. К счастью, в этом проекте у нас есть общий механизм сериализации, поэтому мы создали абстрактный синтаксический анализатор SAX, который мы наследуем, а затем используем тип самоанализа и NSCoding , чтобы преодолеть разрыв между Objective- С и XML. Вы можете сделать аналогичную концепцию самостоятельно.

Перед этим проектом я просто собрал / повторно использовал несколько классов для обработки NSURLConnection и NSXMLParser , но вместо самоанализа типа я использовал Шаблон делегирования .