Здравствуйте, Друзья!
Ломаю голову над такой задачкой:
нужно написать приложение, которое запрос в формате XML переваривала бы в определенный протокол.

XML запрос представляет из себя "команду" вида:

<AddNew>
 <User name="UserName" age="UserAge" address="UserAddress"/>
 <Hardware id="HardwareID" type="HardwareType" power="HardwarePower" count="HardwareCount"/>
 <Linkage user="UserName" hardware="HardwareID"/>
</AddNew>

или

<UpdateOld>
 <User name="UserName" age="UserAge" address="UserAddress"/>
 <Hardware id="HardwareID" type="HardwareType" power="HardwarePower" count="HardwareCount"/>
 <Linkage user="UserName" hardware="HardwareID"/>
</UpdateOld>

Протокол переваривает эти запросы в следующий вид.
Команда AddNew, к примеру, превращается в запрос:

RQ_ADDNEW_USER
{
  char UserName[20];
  byte UserAge;
  char Addres[250];
}

RQ_ADDNEW_HARDWARE
{
  UINT HardwareID;
  BYTE HardwareType;
  UINT HardwarePower;
  BYTE HardwareCount;
}

RQ_ADDNEW_LINKAGE
{
  char UserName[20];
  UINT HardwareID;
}

Посоветуйте, пожалуйста, как организовать архитектуру приложения?
Планируется использовать XML парсер TinyXML. Язык C++.
Задача осложняется тем, что наличие некоторых атрибутов элементов XML запроса необязательно, других — обязательно, то есть необходимо выполнять проверки на наличие определенных элементов.

Мне видится такая картина:
1. объект класса CRequestFactory — получает строку XML запроса. Парсит ее. В зависимости от корневого элемента запроса <AddNew> или <UpdateOld> создает класс соответствующего протокольного запроса CAddRequest или CUpdateRequest, соответственно, и отдает им распарсенные данные, а также указатель на объект-передатчик запроса на сервер.
2. объекты классов CAddRequest и CUpdateRequest на основе распарсенных данных заполняют свои внутренние члены-данные и проверяют их по необходимым условиям (наличие элементов, значения элементов). В случае, если наполнение запроса прошло успешно, объект вызывает функцию объекта-передатчика для отправки запроса на сервер, например:

sender->SendRequest(RQ_RQ_ADDNEW_USER, this->UserName, this->UserAge, this->Addres);

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

Буду благодарен любым советам.

Да, забыл. запросы RQ_ADDNEW_USER и RQ_UPDATE_USER различаются по структуре, в объекте-передатчике запроса для них существуют разные функции отправки.
RQ_UPDATE_USER требует дополнительных преобразований XML запроса, например: подсчета битовой маски и т.п.

Здравствуйте, ifndef, Вы писали:

По-моему, XSLT + XDS самое очевидное решение. Или есть доп. условия?

Здравствуйте, ZevS, Вы писали:

ZS>Или есть доп. условия?

Нужно оценить возможную нагрузку. XSLT относительно ресурсоемкая штука.

Здравствуйте, wildwind, Вы писали:

ZS>>Или есть доп. условия?
W>Нужно оценить возможную нагрузку. XSLT относительно ресурсоемкая штука.

Именно поэтому я и задал вопрос про доп. условия. Для серверного приложения с серьезной нагрузкой можно и тормоза и OutOfMemory получить. Но для небольшой нагрузки + часто меняющиеся запросы + частое добавление новых — самое то.

Здравствуйте, ZevS, Вы писали:

ZS>Именно поэтому я и задал вопрос про доп. условия. Для серверного приложения с серьезной нагрузкой можно и тормоза и OutOfMemory получить.
Это все слова и болтология. Можно подобрать "серьезную нагрузку" когда тормоза и OutOfMemory получится при "вычислении 2+2".


ZevS, не ведитесь на провокации.
ZS>Но для небольшой нагрузки + часто меняющиеся запросы + частое добавление новых — самое то.
Даже при большой нагрузке (что вы, интересно, понимаете под этим?) + нечасто меняющимся запросам + нечастом добавлении новых, XML+XSLT саме то.

СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>ZevS, не ведитесь на провокации.
Почему провокации?

A>Даже при большой нагрузке (что вы, интересно, понимаете под этим?) + нечасто меняющимся запросам + нечастом добавлении новых, XML+XSLT саме то.
Имел ввиду: нагрузку при которой преобразование на XSLT уже не будет удовлетворять требованиям по, например, производительности, а оптимизированный ручной разбор с помощью лекговесного парсера будет. То, что использование XSLT не есть оптимальный с точки зрения производительности вариант думаю понятно.

Здравствуйте, ZevS, Вы писали:

ZS>По-моему, XSLT + XDS самое очевидное решение. Или есть доп. условия?

А что за XDS?

Здравствуйте, _FRED_, Вы писали:

_FR>А что за XDS?

XSD

Здравствуйте, ifndef, Вы писали:

I>Буду благодарен любым советам.

Совет — разделить данные и алгоритмы.

1. на входе мы имеем объекты десериализованные из XML, в чистом виде
2. пропускаем их через необходимые обработчики типа Preprocessor
3. прогоняем его через Validator
4. отправляем через Sender

Основной алгоритм будет примерно таким:

Request request = DeserializeRequest();

ItemVisitor preprocessor = factory.GetPreprocessor(request);
foreach (var item in request.Items)
  preprocessor.Visit(item)

ItemVisitor validator = factory.GetValidator(request);
foreach (var item in request.Items)
  validator.Visit(item)

// здесь как-то обрабатываем возможные ошибки валидации.

ItemVisitor sender = factory.GetSender(request);
foreach (var item in request.Items)
  sender.Visit(item)

Минусы — достаточно большое количество классов: AddPreprocessorVisitor, UpdatePreprocessorVisitor, etc (впрочем скорее всего их можно унаследовать от базового с небольшими отличиями).

Плюсы — везде очень простая и легко поддерживаемая логика.

Абстрактно хорошо бы еще использовать разные типы для XmlUserData->RequestUserData, но, зачастую, можно обойтись и одним.

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

Здравствуйте, Ziaw, Вы писали:

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

Да, еще, XSD может заменить простой валидатор, но легко упереться в его ограниченость, решать вам.

Здравствуйте, _FRED_, Вы писали:

_FR>А что за XDS?

Опечатка.

Здравствуйте, ZevS, Вы писали:

_FR>>А что за XDS?

ZS>Опечатка.

Понятно. Просто смутило то, что xsd вроде как не является обязательным для использования xslt и судя по стартовому сообщению xslt одного вполне хватило бы. Разве нет? Валидация — дело, конечно, важное, но ведь не необходимое же? Или нет?

Здравствуйте, _FRED_, Вы писали:

_FR>Понятно. Просто смутило то, что xsd вроде как не является обязательным для использования xslt и судя по стартовому сообщению xslt одного вполне хватило бы. Разве нет? Валидация — дело, конечно, важное, но ведь не необходимое же? Или нет?

Из исходного поста —

...наличие некоторых атрибутов элементов XML запроса необязательно, других — обязательно, то есть необходимо выполнять проверки на наличие определенных элементов...

Здравствуйте, ifndef, Вы писали:

I>Здравствуйте, Друзья!
I>Ломаю голову над такой задачкой:
I>нужно написать приложение, которое запрос в формате XML переваривала бы в определенный протокол.

I>XML запрос представляет из себя "команду" вида:

I>

I><AddNew>
I> <User name="UserName" age="UserAge" address="UserAddress"/>
I> <Hardware id="HardwareID" type="HardwareType" power="HardwarePower" count="HardwareCount"/>
I> <Linkage user="UserName" hardware="HardwareID"/>
I></AddNew>
I>

...

Я как прикладной человек сделал бы базу полей с конфигом
то есть база вида атрибут/тип/преобразование/валидация

Здесь вообще 2 уровня вложенности. По первому определяем тип команды, по второму — команду. Атрибуты ищем в базе и преобразуем в соответствии со строкой которая стоит в графе "преобразование"