Сначала обозначу ситуацию, а потом опишу сам вопрос.
Имеется приложение, которое отправляет xml-сообщения куда-то (пусть будет "на Сервер"). XML-сообщения, отправляемые на Сервер, должны соответствовать XSD-схемам. Эти схемы поставляются извне, и по ним работает еще N-приложений от M разработчиков. Понятное дело, что схемы могут сильно меняться от версии к версии. Главное условие - мое приложение должно поддерживать текущую версию XSD-схем и 1 предыдущую. Сейчас на уровне кода это реализовано следующим образом. Есть класс, который описывает саму XSD-схему (теги в виде properties). При отправке сообщения на Сервер я как разработчик инициализирую объект нужного класса (читай, "XSD-схемы"), заполняю все нужные properties этого класса (читай, "теги XML") и вызываю метод Send. Этот метод с помощью рефлексии из моего класса формирует XML-строку (да, да, именно объект типа String), которая потом в виде байтов передается в другое приложение. Этот код достался по наследству.
Внимание, вопрос, уважаемые коллеги!
Как лучше организовать код таким образом, чтобы при изменении версии XSD-схем было меньше геморроя? Как Вы формируете сообщения по XSD-схемам?
У меня есть несколько вариантов, постараюсь описать их плюсы и минусы.
1. Оставить как сейчас (когда XSD-схема описывается типом C#). При каждом изменении XSD-схемы вручную менять этот класс. А т.к. нужно поддерживать 2 версии (текущую и предыдущую), то получается, что нужно создавать 2 версии этих классов. При этом один их них будет наследоваться от другого (например, класс MyXsdMessageCurrentVersion описывает XSD-схему. Значит, мне нужно делать 2 класса: MyXsdMessageCurrentVersion - для текущей версии, и MyXsdMessagePreviousVersion - для предыдущей, причем один из них наследуется от другого. Какой от какого - пока не знаю даже...). Плюсы: выше скорость компиляции (по сравнению с вариантом номер 2), понятность для разработчика (работаем с конкретными объектами). Минусы: 1) время разработчика на "ручное" формирование классов C#, 2) "костыли" в виде if....else ("если ...что-то..., то используем текущую версию, иначе - предыдущую). Учитывая, что сообщений очень много, то "костылей" if...else будет тоже очень много. Как-то мне это не очень нравится...
2. Переписать механизм таким образом, чтобы он, используя рефлексию, генерировал объекты C# на основании XSD-схем (реализацию пока что плохо представляю, т.к. особо над ней не думал).
Как мне кажется, у него плюсы: 1) не паришься с классами C#, наследованием классов для поддержания 2 версий XSD-схем. Минусы: 1) приложение из туповатого станет совсем тупым, потому как рефлексия + рефлексия в большом количестве, потому что, напомню, сообщения отправляются ежесекундно и ежеминутно, и 2) значительные затраты ресурсов на переписывание этого механизма (он очень объемный и на нем базируется несколько почти одинаковых приложений).
Как думаете, как лучше решить задачу, чтобы соблюсти условия, но при этом снизить количество "костылей" и реализовать механизм таким образом, чтобы количество вносимых изменений свелось к минимуму?
Есть программа xsd.exe, которая генерирует C# классы из xsd-файла. Можно запускать её перед сборкой проекта - всё сделает. Правда, как поступить с двумя схемами, не очень понятно (читать одной, а если выдала ошибку - то другой?)
Простой
