Насколько модульной должна быть XML-схема?
Говоря о определения схемы, что вы привыкли делать:
- поместить все в уникальную XML-схему большого взрыва?
- использовать подход модульности предметной области, объединяя все сущности, относящиеся к одному контексту?
- или просто использовать схему для каждой сущности?
Я читал в документе с лучшими практиками известного / частного инструмента интеграции, что вам следует модулировать из-за повышения производительности и так далее.
Какой подход лучше?
Ответы 3
По одному на пространство имен. Зачем нужно разбивать схему? Я также процитирую Правила Клуб оптимизации.
Редактировать: Если у вас есть много сущностей, которые не пересекаются друг с другом (например, плагины), может иметь смысл начать применять принцип DRY / модульности и разбить общие части.
Лично по своему опыту я слышал, что с точки зрения производительности нет особой разницы.
На мой взгляд, однако, я считаю, что единую вложенную схему намного проще понять, следовать и связать с исходным документом.
Я процитирую документ с лучшими практиками: «Для лучшей производительности убедитесь, что XML-документ является модульным и небольшим. Рекомендуется иметь отдельные XSD для каждого типа документа».
Одна схема на документ - да, но я не уверен, насколько это влияет на производительность структуры одного документа.
Я думаю, что схема для каждой сущности слишком сильно разносит вещи. Обычно для данной системы у меня есть одна схема, в которой есть все наиболее распространенные типы. Таким образом, когда я говорю о «foo: bar» в одном xsd и «foo: bar» в другом xsd, я знаю, что они эквивалентны. Затем каждый контекст данных входит в другую схему.
Например, если мы говорим о финансовой системе, у меня был бы один xsd с такими типами, как номер заказа, номер счета-фактуры, имя поставщика и т.д ... вещи, которые потребуются для всех видов документов. Тогда будет один xsd для «выставления счетов», один для «заказа», один для «счетов» и так далее. Эти схемы также могут ссылаться друг на друга, и каждая из них будет иметь собственное пространство имен, чтобы упорядочить все необщие типы, которые имеют похожие имена.
Один на пространство имен может показаться слишком абстрактным. Насколько модульными должны быть различия в пространстве имен? У меня может быть "mycompany.com/Customer" (xsd 1), "mycompany.com/Customer/Address" (xsd 2). Но мы можем иметь эти два различия внутри одного и того же.