xsd validation againts xsd генерирует проверку на уровне класса - PullRequest
0 голосов
/ 28 апреля 2009

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

Для приведенного выше сценария у меня может быть 2 подхода

1) Создайте XML, а затем подтвердите соответствие XSD. 2) Создайте классы из XSD с помощью инструмента XSD gen, добавьте xtra бит attirbutes и используйте их для проверки.

Проверка вторым способом будет работать в некотором роде таким образом, а) преобразовать XML-запрос / ответ в объект с XML-сериализацией b) проверять объект с настраиваемыми атрибутами, установленными для каждого свойства, т.е. передавать объект методу, который будет проверять объект путем итерации по свойствам и его настраиваемым атрибутам, установленным для каждого свойства, и это будет возвращать логическое значение, если объект проверяет и это определяет, является ли запрос XML действительным или нет?

Теперь вопрос, какой подход хорош с точки зрения производительности и всего остального ???

Ответы [ 2 ]

1 голос
/ 28 апреля 2009

Если ваша основная проблема - производительность , вам следует использовать XmlReader с подключенной к нему схемой XSD для проверки. Вот пример:

// Store a reference to this object
// to reuse the compiled XSD schema
// for multiple parsing operations
XmlReaderSettings settings = new XmlReaderSettings();
settings.Schemas.Add("http://www.contoso.com/books", "books.xsd");
settings.ValidationType = ValidationType.Schema;

using (XmlReader reader = XmlReader.Create("books.xml", settings))
{
    while (reader.Read())
    {
        // Do parsing logic
    }
}
0 голосов
/ 28 апреля 2009

Я не уверен, что десериализация вашего XML в объект даст вам необходимую вам проверку.

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

Если ваша третья сторона дала вам XSD для проверки, тогда, вероятно, лучше придерживаться этого определения контракта, а не находить короткие пути.

ОДНАКО вы можете обнаружить, что существуют распространенные ошибки и ошибки, которые вы можете быстро отфильтровать. Все зависит от вашего отношения сигнал / шум, но вы можете подумать о создании простого XSD или про грамматического теста, который может «быстро провалиться», прежде чем тратить время на запуск полной XSD. Однако это будет иметь смысл только в том случае, если вы получаете множество сбоев и высокая стоимость полной проверки с помощью XSD.

Кроме того, убедитесь, что вы используете самую быструю проверку XSD для своего сценария. Вы не сказали, является ли это средой .NET или нет, но если это так, у вас есть XmlDocument, XmlValidatingReader и XElement как 3 способа чтения XML и проверки его по схеме. В зависимости от того, откуда вы получаете XML, что вы делаете с ним потом и т. Д., Вы должны оценить, какой из этих механизмов дает вам наилучшую производительность.

...