Ajax для Java разработчиков: Часть 2. Cпособы сериализации данных для Ajax

Пять способов сериализации данных в Ajax-приложениях

Если вы разрабатываете Web-приложения, используя JavaScript и XML (Ajax), то главная задача - это освобождение сервера от данных для работы на машине клиента с ними. Во второй статье Филипп Маккарти расскажет вам о пяти способах сериализации данных.

Филипп Маккарти (Philip McCarthy), консультант и разработчик программного обеспечения, независимый специалист

Филипп Маккарти (Philip McCarthy) - консультант и разработчик программного обеспечения, специализирующийся в области языка Java и Web-технологий. В данный момент он работает в проекте Hewlett Packard над Digital Media Platform в HP Labs, Бристол. В течение последних лет Фил разработал несколько толстых Web-клиентов, применяя асинхронную связь между сервером и машиной сценариев DOM. Он рад, что сейчас у нас есть название для этого. Вы можете связаться с Филом по e-mail: philmccarthy@gmail.com.



26.02.2007

В первой статье этой серии я ввел построение блоков Ajax:

  • Как использовать XMLHttpRequest объект, чтобы послать асинхронный запрос серверу с Web-страницы
  • Как обрабатывать и отвечать на запрос с помощью Java сервлета, возвращая XML-документ клиенту
  • Как использовать документ ответа на запрос клиента для обновления вида вашей страницы

Сейчас я продолжу обсуждать основы разработки в Ajax, но сконцентрируюсь на том, что больше всего волнует многих Web-разработчиков на языке Java: создание данных для клиента.

Большинство Java-разработчиков применяют шаблон Модель-Вид-Контролер (MVC) для своих Web-приложений. В обычном Web-приложении компонент вида (view component) состоит из JSP или, возможно, другой технологии представлений, такой как шаблон Velocity. Компоненты этого представления обновляют интерфейс пользователя, динамически производят целую новую страницу HTML, замещая предыдущую. Однако, в Web-приложениях, написанных на языке Java и с применяемой технологией Ajax, клиентская часть кода JavaScript максимально ответственна за обновление вида страницы, которую видит пользователь. Оно основано на данных, приходящих в соответствии с XMLHttpRequest. С точки зрения сервера вид становится представлением данных, которое он шлет в соответствии с запросами клиента.

В этой статье мы сконцентрировали внимание на технических приемах, которые вы можете использовать, чтобы создавать представления Java-объектов, основанных на данных. Я продемонстрирую множество методов, которые вы можете использовать для возвращения JavaBeans в XML-документы, и вы узнаете достоинства и недостатки каждого. Вы также увидите, почему XML - это не всегда выход: передача обычного текста может быть выгоднее. Наконец, я познакомлю вас с записью объектов в JSON. JSON позволяет данным передаваться в форме схемы сериализуемых данных JavaScript, которая чрезвычайно удобна для работы в коде клиента.

О примере

Я применю одно показательное приложение и несколько прецедентов для того, чтобы проиллюстрировать вам особенности технологии и техники, о которых будет рассказано здесь. Рисунок 1 показывает чрезвычайно простую модель данных, которая иллюстрирует случаи использования примера. Модель представляет счет покупателя в действующем он-лайн магазине. У покупателя есть набор предыдущего ряда покупок, каждый из которых состоит из нескольких продуктов.

Рисунок 1. Простая модель объекта
Модель объекта, представляющая счет покупателя

Несмотря на то, что XMLHttpRequest не накладывает никаких ограничений на формат, используемый для отправки данных запроса, в большинстве случаев предпочтительнее всего оказывается послать просто обычные параметры формы, поэтому в ходе обсуждения мы сконцентрируем внимание на запросе сервера. Запрос может также быть любого текстового формата, но, в связи с согласованием имен, у XMLHttpRequest есть встроенные возможности по работе с данными XML запроса. Это делает XML хорошим выбором для Ajax запросов по умолчанию, поскольку начинать с этого достаточно удобно.

XML из Java-классов

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

Я рассмотрю три способа, которые вы можете использовать для производства XML-данных из Java-объектов и рассмотрю достоинства и недостатки каждого.


Запустите свою собственную сериализацию

Прежде всего, вы могли бы сгенерировать XML прямо из вашего графа объектов. Этот подход может быть также прост, как и toXml() метод в каждом из ваших JavaBean-классов. Потом Вы, возможно, подберете подходящий интерфейс XML API и сделаете для каждого выпускающегося bean элемента представление и будете рекуррентно вызывать компоненты графа объекта. Ясно, что такой метод не справится с большим числом классов, так как каждому классу нужно будет написать свой собственный создающий XML код. С другой стороны это достаточно простой метод для реализации, в котором нет перегрузки из-за дополнительной конфигурации или все более усложняющегося процесса построения, и не требуется другая схема, составленная из ваших JavaBeans, которые можно превратить в XML-документ с помощью пары вызовов.

В коде примера предыдущей статьи этой серии, я реализовал toXml() методы, прибавив строки XML. Как я уже упомянул ранее, это ограниченный метод, поскольку он вводит объемный код для подтверждения задумываемых ссылок, зашифрованных данных и так далее для каждого метода toXml(). Несколько интерфейсов API XML доступны на Java-платформе для выполнения всей этой работы за вас, позволяя вам сконцентрироваться на контенте XML. Листинг 1 использует для реализации toXml() в классе, представляющим из себя очередь в примере базы данных (см. рисунок 1).

Листинг 1. JDOM реализация toXml() для класса Order
public Element toXml() {

  Element elOrder = new Element("order"); 
  elOrder.setAttribute("id",id);

  elOrder.setAttribute("cost",getFormattedCost());

  Element elDate = new Element("date").addContent(date); 
  elOrder.addContent(elDate);

  Element elItems = new Element("items"); 
  for (Iterator<Item> iter = 
    items.iterator() ; iter.hasNext() ; ) { 
      elItems.addContent(iter.next().toXml()); 
  } elOrder.addContent(elItems);

    return elOrder; 
 }

Теперь вы видите, как просто создать элементы, установить атрибуты и добавить содержимое элемента при помощи JDOM. Рекурсивные вызовы для составления JavaBeans toXml() методов предназначены для Element представлений их подсхем. К примеру, содержимое элемента items генерируется здесь с помощью вызова toXml() для каждого объекта Item, подсчитываемого Заказа - Order.

Когда все ваши JavaBeans выполнят метод toXml(), будет легко сериализовать любую произвольную схему объектов в XML документ и возвратить его Ajax-клиенту, как показано в листинге 2.

Листинг 2. Генерирование XML-запроса из JDOM-элемента
 public void doGet(HttpServletRequest req, HttpServletResponse res)
  throws java.io.IOException, ServletException {

    String custId = req.getParameter("username");
    Customer customer = getCustomer(custId);

    Element responseElem = customer.toXml();
    Document responseDoc = new Document(responseElem);

    res.setContentType("application/xml");
    new XMLOutputter().output(responseDoc,res.getWriter());
}

JDOM опять упростит вам жизнь. Вам всего лишь необходимо создать для XML-элемента, возвращенного схемой объекта, Document и затем использовать XMLOutputter для переписывания сервлета запроса. Листинг 3 показывает пример XML, выполненный таким способом, форматированный инициализацией XMLOutputter при помощи Format.getPrettyFormat() JDOM. В этом случае покупатель составил единственно возможный порядок, состоящий из двух вещей.

Листинг 3. Пример XML-документа, представляющий покупателя
<?xml version="1.0" encoding="UTF-8"?>
<customer username="jimmy66">
  <realname>James Hyrax</realname>
  <orders>
    <order id="o-11123" cost="$349.98">
      <date>08-26-2005</date>
      <items>
        <item id="i-55768">
          <name>Oolong 512MB CF Card</name>
          <description>512 Megabyte Type 1 CompactFlash card. 
          Manufactured by Oolong Industries</description>
          <price>$49.99</price>
        </item>
        <item id="i-74491">
          <name>Fujak Superpix72 Camera</name>
          <description>7.2 Megapixel digital camera featuring six 
          shooting modes and 3x optical zoom. 
          Silver.</description>
          <price>$299.99</price>
        </item>
      </items>
    </order>
  </orders>
</customer>

Недостатки запуска своей собственной реализации

Интересно, что код в листинге 7 показывает один из главных недостатков сериализации JavaBeans вручную в XML. Представьте, будто этот документ использовался для представления покупателю истории Order. В этом случае вы, скорее всего, не захотите, чтобы на экране было полное описание каждой вещи, прошедшей очереди или чтобы пользователю говорилось полное его имя. Но если бы у приложения был ProductSearch класс, который возвращает результаты поиска в виде списка Item beans, было бы весьма полезно, чтобы описания включались в Item, представляющий собой уровень стока в данный момент, могло быть полезной информацией для вывода на экран в списке "Поиск продукта" (Product Search). Однако, это поле могло быть затем сериализовано из другой схемы объектов, включающей в себя Item, несмотря на неуместность уровня стока в данный момент для истории Order покупателя.

С точки зрения разработки, это является классической проблемой модели данных, соединенной с генерацией представления. Каждый bean может сериализовать себя только одним способом, и универсальный метод обозначает, что взаимодействия в Ajax закончатся обменом данных, который им не нужен, усложняя работу кода клиента при локализации информации, которую оно затребует из документа, а также увеличения объема отработки и времени анализа XML на машине клиента. Другим следствием этого соединения является то, что XML не может создаваться независимо от Java-классов. К примеру, чтобы сделать изменения в документе схемы покупателя, могла бы потребоваться группа нескольких Java-классов, которые бы затем стоило модифицировать и перекомпилировать.

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


XML-структура связывания

За последнее время несколько Java -интерфейсов (API) были разработаны для упрощения процесса связывания XML-документов и представлений схем Java-объектов. В большинстве случаев маршрутизация XML как обеспечивается, так и не обеспечивается: в обоих случаях выполняются двухсторонние конверсии Java-схем объектов в представление XML. Эти структуры заключают в себя всю работу по поддержке XML, обозначая, что код приложения теперь необходимо писать только для обычных Java-объектов. Скорее всего, они также предназначаются для обеспечения полезных прикладных функций, таких как валидирование. В общих чертах эти структуры содержат два различных подхода: генерация кода и отображение "XML-объект". Я объясню оба эти подхода.

Метод генерации кода

Схемы связывания, которые включают в себя генерацию кода, выполняются при помощи программ, таких как XMLBeans, JAXB, Zeus и Jbind. Castor также может применить эту технику. Началом любой структуры является XML-схема, которая описывает типы данных ваших документов. Используя средства, обусловленные структурой, вы затем генерируете Java-классы, которые представляют эти определенные схемой типы. Наконец вы пишите ваше приложение, используя эти сгенерированные классы для представления ваших данных модели и сериализации их в XML при помощи удобного механизма, обусловленного структурой.

Подход генерации кода очень хорош, когда ваше приложение обрабатывает большой объем XML-данных. Существует определенная проблема написания обычной XML-сериализации методов для десятков классов. С другой стороны вам больше не потребуется определять ваши собственные JavaBean. Java-классы, сгенерированные структурой, обычно следуют за XML-структурами, что может приводить к тому, что они будут чрезвычайно громоздки для кода. Также сгенерированные классы иногда становятся мусором, поскольку вы не можете просто добавить к ним тип. Образно говоря, вам потребуется пойти на компромисс в вашем коде приложения, чтобы вдоволь поиграть с сгенерированными структурой типами. Другим "подводным камнем" является то, что изменение в схеме приведет к модификации в сгенерированных классах, что может нанести большой вред приложениям, написанным с такими классами.

XML-структуры связывания такого типа наиболее полезны в расположении данных (т. е, использовании XML-документов и преобразовании их в Java-объекты). До тех пор пока у вас не будет модели данных для большого объема и вы не захотите получить пользу от использования классов, сгенерированных для вас, структуры, основанные на генерации кода, возможно, будут излишними для Ajax-приложений.

Отображения

Структуры, которые создают отображения, включены в такие программы, как Castor и Apache Commons Betwixt. Отображение обычно более гибкое и легковесное решение, чем генерация кода. Во-первых, вы пишете код ваших JavaBeans так, как вы обычно писали, включая любые типы и какие бы то ни было удобные для вас методы. Во-вторых, во время выполнения вы вызываете маршрутизатор, основанный на самоанализе структуры, и он создает XML-документ, основанный на типах, именах и значениях компонентов ваших классов. Определив отображение файлов в ваших классах, вы можете переписать стратегию связывания, которая установлена по умолчанию, и объявить маршрутизатор в соответствии с тем, как ваши классы будут представлены в XML.

Этот метод является оптимальным компромиссом между масштабностью и гибкостью. Вы можете писать ваши Java-классы так, как вы хотите, и маршрутизатор спасет вас от работы с XML. Однако, несмотря на то, что определение файлов отображения легко написать и достаточно уверенно соотнести, правила отображения могут меняться только в соответствии со стандартным поведением связывания, и некоторая степень связности структуры ваших объектов и их XML-представления всегда будет оставаться. В конечном итоге вы, должно быть, сможете найти компромисс либо в ваших Java-представлениях, либо в вашем XML-формате работы метода отображения.

Итог привязки данных

Денис Сосновский написал достаточно много статей на предмет XML-привязки данных интерфейсов (API) и для генерации кода, и для отображения кода. Я бы вам рекомендовал почитать его превосходные статьи по Castor и по структурам генерации кода, если вы хотите дальше продвинуться в этой области (см. Ресурсы для ссылок).

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

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

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


Системы шаблонов страниц

Любая технология шаблона широко используемых страниц может быть использована для генерации XML, позволяя Ajax-приложениям создавать произвольный XML-документ запроса из его модели данных. Плюс еще в том, что образцы могут быть написаны, с использованием простого и выразительного языка, в отличие от строк кода, написаннного на языке Java. Листинг 4 - страница JSP, которая объявляет Customer bean и возвращает обычное представление XML, подходящее для кода клиента, чтобы создать компоненты истории Order.

Листинг 4. Страница JSP, которая производит компонент истории order
<?xml version="1.0"?>
<%@ page contentType="application/xml" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<c:set var="cust" value="${requestScope.customer}"/>

<orderhistory username="${cust.username}">
<c:forEach var="order" items="${cust.orders}">
  <order id="${order.id}" cost="${order.formattedCost}">
    <date>${order.date}</date>
    <items>
    <c:forEach var="item" items="${order.items}">
      <item id="${item.id}">
        <name><c:out value="${item.name}"
         escapeXml="true"/></name>
        <price>${item.formattedPrice}</price>
      </item>
    </c:forEach>
    </items>
  </order>
</c:forEach>
</orderhistory>

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

Проблемы, возникающие при использовании шаблонов

Обратной стороной медали является необходимость создавать новый JSP для каждого различающегося вида, который нам потребуется, в отличие от компоновки требуемых схем объектов и сериализации их. С точки зрения разработки многие могли бы поспорить, что это будет в любом случае выходом, поскольку это означает формальную обработку типов документа, которые произведет сервер. Также поскольку мы теперь работаем, в основном, со средой шаблона и не в специфичных интерфейсах (XML API), моей обязанностью будет убедиться, что ссылки определены, элементы и порядок атрибутов корректены, и любые ошибки (к примеру, < или &) исправлены. Основной JSP тег out легко выполняет последнее задание, но не все технологии шаблонов справляются с этим. Наконец, нет легкого пути валидирования сгенерированного XML-документа в соответствии со схемой сервера, и это в любом случае не то, чего вы ожидали от среды, но вы можете легко работать с ними в рамках разработки.


Получение данных без использования XML

Все техники, с которыми я вас ознакомил, производят запрос сервера в форме XML-документа. Есть другие методы, связанные с XML, действие одного из которых может показаться скрытым. Браузеры не анализируют XML-документы и тотчас же создают DOM-модели, и это может уменьшить быстродействие, порой необходимое для Ajax-компонентов, особенно если идет анализ больших документов на медленных машинах. Примером является "поиск он-лайн", где результаты поиска сразу берутся с сервера и показываются пользователям, будто они сразу печатаются в формах поиска. Для компонент такого поиска важно быстро реагировать на ввод данных, но в тоже время необходимо анализировать запросы сервера быстро в течение длительного времени.

Скрытые процессы - важный момент в рассмотрении моделей, но важнейшей причиной для избегания XML являются неудобные интерфейсы (API DOM) клиента. Листинг 5 показывает диапазон, в который вам нужно попасть, чтобы получить значение с помощью DOM, в случае нескольких поддерживаемых браузеров.

Листинг 5. Работа с XML документом запроса в JavaScript
// Найти имя первой вещи в последней очереди покупателя 				
var orderHistoryDoc = req.responseXML;

var orders = orderHistoryDoc.getElementsByTagName("order"); 
var lastOrder = orders[orders.length - 1];

var firstItem = lastOrder.getElementsByTagName("item")[0]; 
var itemNameElement = firstItem.firstChild;

var itemNameText = itemNameElement.firstChild.data;

Процесс все более усложняется и возникают некоторые пробелы между элементами, поскольку каждый элемент firstChild постоянно попадает в некоторое затруднение. JavaScript-библиотеки применимы для упрощения работы с XML-документами. Они включают в себя Sarissa (см. Ресурсы) и Google-ajaXSLT, оба из которых добавляют функции Xpath к большинству браузеров.

Тем не менее стоит задуматься об альтернативах. В добавление к responseXML, XMLHttpRequest объект предлагает свойство, называющееся responseText, которое просто представляет собой тело ответа сервера как строку.

Свойство responseText

Метод responseText особенно удобен, когда серверу необходимо отправить очень простые значения клиенту, избегая использования большой полосы пропускания и перегрузок XML. К примеру обычный запрос true/false может быть возвращен как обычный текст, а также может быть простым списком имен или чисел, разделенных запятой. Хотя обычно лучше не смешивать XML-запросы и текстовые запросы в одном приложении, использование только одного формата данных сделает абстракцию кода и повторное его использование проще.

responseText может быть также полезен в комбинации с данными XML-запроса. В сценарии, где вам всего лишь необходимо получить единственное значение из документа запроса, лучше всего "сжульничать", обращаясь к XML как к строке текста, а не как к структурированному документу. К примеру листинг 6 показывает, как обычные выражения могут быть использованы для получения данных первой очереди в истории Order покупателя. Это действительно "необычное" решение, ведь, в основном, вам не следует полагаться на лексическое представление XML-документа.

Листинг 6. Использование обычного выражения в объекте responseText от XMLHttpRequest
var orderHistoryText = req.responseText; 
var matches = orderHistoryText.match(/<date>(.*?)<\/date>/);

var date = matches[1];

Использование responseText в этом ad-hoc понимании может быть удобным при некоторых обстоятельствах. В идеале, однако, мог бы существовать способ представления сложных и структурированных данных в формате, который легко бы поддерживал JavaScript, и он не имел бы перенагрузок XML. К счастью, такой формат существует.


Запись объектов в JavaScript (JSON)

Приоткрывая завесу, обнаружим, что JavaScript-объекты большинства приложений состоят из коммуникабельных массивов, пронумерованных массивов, строк, чисел и комбинаций этих типов. Поскольку все типы могут быть объявлены буквально в JavaScript, возможно статически определить схему объектов единственным способом. Листинг 7 объявляет объект при помощи синтаксиса JSON и показывает, как к нему организовать доступ. Квадратные скобки обозначают нумерацию массива.

Листинг 7. Объявление простого объекта буквенно в JavaScript при помощи JSON
 var band = {
  name: "The Beatles",
  members: [
    {
      name: "John",
      instruments: ["Vocals","Guitar","Piano"]
    },
    {
      name: "Paul",
      instruments: ["Vocals","Bass","Piano","Guitar"]
    },
    {
      name: "George",
      instruments: ["Guitar","Vocals"]
    },
    {
      name: "Ringo",
      instruments: ["Drums","Vocals"]
    }
  ]
};

// Распознаем семейство объектов 
var musician = band.members[3];
alert( musician.name
        + " played " + musician.instruments[0] 
        + " with " + band.name );

Таким образом, JSON - интересная особенность языка, но что она делает с Ajax? Суть в том, что вы можете использовать JSON для отправления JavaScript-схемы объекта по сети в Ajax-запросе сервера. Это позволит избежать обработки XML в клиенте с использованием громоздкого интерфейса DOM API, - вам всего лишь придется обработать JSON-запрос, и вы сразу же получите доступную схему JavaScript-объекта. Сначала, однако, вам может понадобиться преобразование вашего JavaBeans в JSON.

Создание JSON из Java-классов

Достоинства и недостатки, которые могут быть найдены в других способах создания XML, могут оказаться верными для JSON. Возможно, существует еще один случай использования технологий шаблона представления. Однако, использование JSON логически ближе к использованию сериализации данных для ряда приложений, чем к созданию представления состояния приложения. Я собираюсь показать вам, как использовать org.json и toJSONObject() при создании toJSONObject() методов в ваших Java-классах. Ваш JSONObject может также быть легко сериализован в JSON. Листинг 8 напоминает нашей дискуссии о XML, показывая toJSONObject() реализацию для Order класса.

Листинг 8. toJSONObject() реализация метода для класса Order

Как вы можете видеть, API-интерфейс org.json очень прост. JSONObject представляет собой JavaScript-объект (коммуникативный массив) и выполняет различные put() методы, которые используют String ключ и значение String, или другого JSON типа. JSONArray представляет собой непронумерованный массив, поэтому его put() метод запрашивает только одно значение. Запомните, что листинг 8, альтернатива созданию jsonItems массива и последующее этому закрепление его за json объектом с put() методом, должен был вызывать json.accumulate("items",iter.next().toJSONObject()); для каждой вещи. accumulate() метод подобен put() за исключением того, что он привязывает значение к индексируемому массиву, определенному ключом.

Листинг 9 показывает, как сериализовать JSONObject и написать его в соответствии с запросом сервлета.

Листинг 9. Генерация сериализованного JSON запроса из JSONObject

toString() метод в JSONObject, вызванный здесь же, выполняет всю работу, поэтому на вашу долю не остается, практически, ничего. Запомните, что тип содержимого application/x-json несколько сомнителен, во время написания этих строк мы не пришли к консенсусу, к какому MIME типу JSON его следует отнести. Однако, application/x-json - разумный выбор. Листинг 10 показывает запрос примера из этого кода сервлета.

Листинг 10. JSON-представление Customer-bean

Использование JSON на стороне клиента

Заключительным моментом процесса будет преобразование JSON-данных в JavaScript-объекты на стороне клиента. Это может быть выполнено с помощью простого вызова eval(), функции, которая переводит строки, содержащие JavaScript-выражения в поток. Листинг 11 показывает преобразование JSON-запроса в JavaScript-схему объекта и затем выполняет задание листинга 5 для получения имени первой вещи из последней очереди покупателя.

Листинг 11. Оценка JSON-запроса

Сравнение листинга 11 с листингом 5 иллюстрирует преимущества использования JSON на стороне клиента. Если ваш Ajax-проект включает в себя работу с большим потоком сложных запросов к серверу на стороне клиента, JSON может, несомненно, помочь вам. Связывание JSON и XMLHttpRequest вместе приведет к тому, что работа с Ajax начнет выглядеть как вызов RPC, а не как запрос SOA, который может привнести надежность в разработку вашего приложения. В следующей статье я рассмотрю схемы, предназначенные для того, чтобы JavaScript-код делал вызовы удаленных процедур для объектов сервера.

Недостатки JSON

У JSON есть свои недостатки. Используя подход JSON, проиллюстрированный здесь, нет пути приспособить сериализацию объектов для основных данных по запросу, поэтому ненужные поля могут часто отправляться по сети. Кроме того, добавление toJSONObject() методов к каждому JavaBean не достаточно определено, хотя можно было просто написать обычный JavaBean для JSON-сериализатора с использованием самоанализа и замечаний. Наконец, если ваш код сервера связан со службами и не используется только для поддержания запросов из Ajax-клиента, то в этом случае лучше всего использовать XML из-за универсальной поддержки.


Сравнение техник сериализации

Мы рассмотрели пять различных техник для передачи Java-состояния Ajax-клиенту. Я рассказал о XML-сериализации, созданной собственноручно, XML-связывании при помощи генерации кода, XML-привязке при помощи механизма отображения, XML-генерации, основанной на шаблонах, и наконец JSON-сериализации вручную. Каждая техника имеет свои преимущества и недостатки.

Подводя итог достоинствам и недостаткам каждого подхода, таблица 1 определяет приблизительные баллы по шести категориям:

Масштабность
Описывает, насколько подход хорошо адаптируется к большому количеству типов данных. Увеличится ли объем работы написания вашего кода и конфигурации, если использовать дополнительные типы?
Оценка интерграции
Оценивает, насколько просто интегрировать технологию в ваш проект. Приводит ли это к более громоздкому процессу построения? Увеличивает ли это сложность?
API-интерфейсы Java-класса
Описывает, как легко работать с Java-объектами сервера, используемыми в этом методе. Придется ли вам писать обычные bean или может быть вам придется работать с неудобными представлениями документа?
Контроль выхода данных
Описывает, насколько точно вы можете контролировать сериализованное представление ваших классов.
Разнообразие вида
Оценивает, какое многообразие измененных сериализаций данных может быть создано из одного набора объектов.
Доступ данных к клиенту
Описывает, насколько легко JavaScript-коду работать с запросом данных с сервера
alt-rowalt-rowalt-row
Таблица 1. Соответствующие значения техник генерации данных
Запуск своего собственного XMLXML-связывание при помощи генерации кодаXML-связывание при помощи отраженияШаблон XML-страницJSON-сериализация вручную
МасштабностьПлохоХорошоУдовлетворительноУдовлетворительноПлохо
Оценка интерграцииХорошоПлохоУдовлетворительноУдовлетворительноХорошо
API-интерфейсы Java-классаХорошоПлохоХорошоХорошоХорошо
Контроль выхода данныхХорошоХорошоУдовлетворительноХорошоХорошо
Разнообразие видаПлохоПлохоПлохоХорошоПлохо
Доступ данных к клиентуПлохоПлохоПлохоУдовлетворительноХорошо

Заключение

Данные, собранные в таблице 1, не утверждают, что одни техники сериализации лучше, чем другие. После всего сравнительная важность каждой из шести категории зависит от специфики вашего проекта. К примеру, вы будете работать с сотнями типов данных, вы хотите масштабности, поэтому генерация кода, возможно, ваш лучший выбор в этом случае. Если вам понадобится генерировать несколько различных представлений одной и той же модели данных, шаблоны страниц - выход для этого случая. Если вы работаете над небольшим проектом и хотите уменьшить количество JavaScript-кода, следует использовать JSON-представление.

Я надеюсь, что эта статья обеспечила вас всей необходимой информацией для выбора технологии сериализации, которая больше всего подходит для вашего приложения. Смотрите секцию Ресурсы чтобы узнать больше о технологиях, о которых рассказано здесь. Вам следует также посмотреть следующую статью этой серии, где я покажу вам, как написать Ajax-приложение на языке Java при помощи Direct Web Remoting (DWR). DWR-схема позволит вам вызвать методы ваших Java-классов прямо из JavaScript-кода. Другими словами, она возьмет на себя работу по сериализации данных, поэтому вы можете использовать Ajax на более высоком уровне абстракции.

Ресурсы

Научиться

Получить продукты и технологии

  • Sarissa: JavaScript-библиотека для перекрестных браузеров с поддержкой XPath
  • Jakarta Commons Betwixt: адаптируемая библиотека XML связки, основанная на отражении.
  • JSON: API-интерфейсы для JavaScript-кода и для языка Java, а также других языков.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML, Технология Java
ArticleID=197985
ArticleTitle=Ajax для Java разработчиков: Часть 2. Cпособы сериализации данных для Ajax
publish-date=02262007