Разработка классов вокруг разбора StAX - PullRequest
Новая
       0

Разработка классов вокруг разбора StAX

2 голосов
/ 17 января 2011

Это вопрос разработки, а не вопроса, специфичного для Java, но я разрабатываю его для Java.

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

Итак, вот как может выглядеть мой XML: 

<ResponseRoot>
  <Header>
    <RequestId />
    <OtherHeaderMetaData />
  </Header>
  <Body>
    ...
    <!-- Lots of other elements and nested elements -->
    ...
  </Body>
</ResponseRoot>

Итак, в зависимости от RequestId (своего рода ключ),Body элемент отличается.Учитывая, что это разбор по запросу, у меня был бы большой оператор switch и много блоков if-else-if.

Было бы более эффективно для одного класса с большим количеством статических методов обрабатывать весь поток XMLили было бы лучше сделать так, чтобы один класс отвечал за каждый RequestId?

Я думал о сопоставлении RequestId с именем класса, а затем, когда я нажимаю Body, я используюфабрика для извлечения соответствующего подпарсера.Внутри этой фабрики я мог бы даже использовать отображение Class экземпляров и использовать отражение для создания экземпляра соответствующего синтаксического анализатора (поскольку не все анализаторы нужны все время).Или ... используйте отражение, чтобы получить соответствующий статический анализ метод вместо этого, поэтому мне не нужно создавать экземпляры синтаксических анализаторов, которые на самом деле являются классами только 1 использования ...

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

Ответы [ 3 ]

4 голосов
/ 17 января 2011

Таким образом, в зависимости от RequestId (своего рода ключа), элемент Body может быть разным.

Можете ли вы изменить дизайн XML так, чтобы действительный элемент body не зависел от запроса-ID, но определяется целиком окружающим элементом ответа?Тогда достоверность документа (соответствие DTD) будет соответствовать действительности ответа на сообщение.

Вместо использования оператора switch рассмотрите возможность использования шаблона проектирования состояния .То есть реализуйте ваш обработчик документов как конечный автомат.

2 голосов
/ 17 января 2011

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

Одна вещь, которая важна для StAX, заключается в том, что в документации каждого метода обработки вы должны описать, в каком состоянии этот метод ожидает ввод (например, до или после обработки открывающего тега <body>) и где он оставляет вход после обработки. Таким образом вы можете сэкономить много времени на отладке.

1 голос
/ 17 января 2011

Вместо того, чтобы возлагать ответственность за анализ каждого пользовательского объекта XML на анализатор StAX, почему бы не сделать так, чтобы анализатор StAX создал промежуточное представление объекта XML?Тогда у вас может быть фабрика, которая будет создавать окончательное представление объекта XML с использованием RequestID.Код будет выглядеть примерно так: 

IntermediateObject io = StAX.parse(XML);
FinalObject = Factory.create(io.getRequestID, io);

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...