Авторское право © WWW : Качественный хостинг сайтов и регистрация доменов
Перепубликация материалов,возможна только с устного или письменного разрешения Администрации сайта !
Название статьи , Опубликовано Документация » Статьи » Web-программирование » AJAX » Ajax для Java разработчиков: Часть 2. Cпособы сериализации данных для Ajax
25 Май 2008 01:06

Если вы разрабатываете Web-приложения, используя JavaScript и XML (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"?>

James Hyrax


08-26-2005


Oolong 512MB CF Card
512 Megabyte Type 1 CompactFlash card.
Manufactured by Oolong Industries
$49.99


Fujak Superpix72 Camera
7.2 Megapixel digital camera featuring six
shooting modes and 3x optical zoom. Silver.
$299.99

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

Интересно, что код в листинге 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" %>





${order.date}




${item.formattedPrice}

Этот весьма краткий шаблон выводит только данные, необходимые для вида истории 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

public JSONObject toJSONObject() {

JSONObject json = new JSONObject();
json.put("id",id);
json.put("cost",getFormattedCost());
json.put("date",date);

JSONArray jsonItems = new JSONArray();
for (Iterator<Item> iter =
items.iterator() ; iter.hasNext() ; ) {
jsonItems.put(iter.next().toJSONObject());
}
json.put("items",jsonItems);

return json;
}

Как вы можете видеть, 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

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws java.io.IOException, ServletException {

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

        res.setContentType("application/x-json");
        res.getWriter().print(customer.toJSONObject());
}

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

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

{
"orders": [
{
"items": [
{
"price": "$49.99",
"description": "512 Megabyte Type 1 CompactFlash card.
Manufactured by Oolong Industries",
"name": "Oolong 512MB CF Card",
"id": "i-55768"
},
{
"price": "$299.99",
"description": "7.2 Megapixel digital camera featuring six
shooting modes and 3x optical zoom. Silver.",
"name": "Fujak Superpix72 Camera",
"id": "i-74491"
}
],
"date": "08-26-2005",
"cost": "$349.98",
"id": "o-11123"
}
],
"realname": "James Hyrax",
"username": "jimmy66"
}

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

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

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

var jsonExpression = "(" + req.responseText + ")";
        var customer = eval(jsonExpression);

// Найдем имя первой вещи в последней очереди покупателя
var lastOrder = customer.orders[customer.orders.length-1];
var name = lastOrder.items[0].name;

Сравнение листинга 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, не утверждают, что одни техники сериализации лучше, чем другие. После всего сравнительная важность каждой из шести категории зависит от специфики вашего проекта. К примеру, вы будете работать с сотнями типов данных, вы хотите масштабности, поэтому генерация кода, возможно, ваш лучший выбор в этом случае. Если вам понадобится генерировать несколько различных представлений одной и той же модели данных, шаблоны страниц - выход для этого случая. Если вы работаете над небольшим проектом и хотите уменьшить количество JavaScript-кода, следует использовать JSON-представление.

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