Генерация кода WCF для большой / сложной схемы (HR-XML / OAGIS) - есть ли альтернатива?

Question

и спасибо за чтение.

Я внедряю службу WCF на основе предварительно определенной спецификации (HR-XML 3.0). Поэтому я начинаю со схемы и возвращаюсь к коду. Существует ряд крупных документов Schema (которые импортируют еще больше документов Schema), связанных с моей реализацией, предоставленных этой спецификацией.

Я могу сгенерировать код, используя xsd.exe, указав в качестве аргументов "основной" и "поддерживающий" файлы xsd. Но есть несколько вопросов, и мне интересно, если это правильный подход.

• существует несколько сотен классов - размер файла кода составляет полмегабайта
• дубликаты классов (например, Type, Type1 - которые оба представляют один и тот же тип)
• существуют классы, объявленные как унаследованные от базового класса, но этот базовый класс не создан / не определен

Я понимаю, что существуют ограничения для типов схем, поддерживаемых svcutil.exe / xsd.exe при нацеливании на DataContractSerializer и даже XmlSerializer. У меня вопрос двоякий:

1. Являются ли проблемы с генерацией кода достаточно распространенными при работе с большими модульными xsd-файлами? Кто-нибудь имел успех в создании контрактов данных из схемы OAGIS или HR-XML?
2. Учитывая вышеперечисленные проблемы, существуют ли лучшие подходы к этой задаче, позволяющие избежать генерации кода и работы с конкретными объектами? Лучше ли читать и составлять сообщения SOAP напрямую, но при этом использовать преимущества остальной части инфраструктуры WCF? Я понимаю, что теряю удобство работы с объектами .NET и сериализацию, предоставляемую фреймворком; Учитывая эти потери, будет ли по-прежнему выгодно основывать мой Сервис на WCF? Есть ли какая-то "золотая середина" между работой с типами .NET и чистым XML?

Большое спасибо!

- Саша Бородин DFWHC.org

Answer 1

Саша, если вы собираетесь использовать генерацию кода, вам, вероятно, никогда не следует начинать с модульных схем. Когда вы добавляете генератор кода к модульным схемам, вы генерируете класс для всех общих компонентов в библиотеке HR-XML и большого количества общих компонентов в OAGIS. Ты не хочешь этого. HR-XML распространяется с автономными схемами, которые являются лучшей отправной точкой. Еще лучшей отправной точкой было бы создание плоского пакета xsd, содержащего только типы, введенные WSDL. Если вы используете несколько автономных схем, вы, по крайней мере, будете иметь некоторые дубликаты среди вашего сгенерированного кода.

Answer 2

Ну, вы можете попробовать сделать что-то вроде этого:

• конвертируйте XSD в код C # отдельно, используя что-то вроде xsd.exe от Microsoft или что-то вроде Xsd2Code в качестве плагина Visual Studio.

Xsd2Code в Visual Studio http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=Xsd2Code&DownloadId=41336

• когда у вас есть классы C #, отсеивайте любые несоответствия, дубликаты и т. Д.

• упаковать все в отдельную сборку библиотеки классов

• теперь при создании службы WCF из WSDL, используя Add Service Reference из Visual Studio или инструмент svcutil.exe, укажите ссылку на эту сборку со всеми классами данных. При этом WCF должен пропустить повторное создание всего набора классов и использовать все, что доступно в этой сборке данных

С этим вы, возможно, сможете взять под контроль этот беспорядок.