Я должен был бы предположить, что: i) некоторые из того, что вы бы назвали необязательными полями, на самом деле являются полями, которые не применимы (не имеют смысла) ко всем учетным записям, и ii) мы не говорим о тривиальных сценариях (например, дватипы учетных записей с 2 полями для каждого типа вещей).
Во-первых, я бы сказал, что если вам не повезет, с точки зрения требований, то вы в конечном итоге получите какое-то "проверка во время выполнения "независимо от того, какой вариант вы собираетесь.Схема XML не может выражать некоторые общие требования к проверке данных, такие как межполевая проверка;или просто потому, что данных в вашем XML недостаточно для подачи правил для проверки целостности сообщения (данные в сообщении являются подмножеством того, что доступно в то время, когда XML выводится / маршалируется).
Во-вторых, я бы не стал выводить новые сложные типы с помощью рестриктонов;с точки зрения разработки вы не достигаете многого с точки зрения повторного использования, и у вас могут возникнуть проблемы с тем, как это интерпретируется вашим XSD для инструментов кода.Мне нравится думать, что первоначальное намерение получить через ограничение состояло в том, чтобы предоставить людям инструмент для использования в xsd: переопределить сценарии;для людей, которые не хотят возиться с XML-схемами, созданными кем-то другим.Если кому-то принадлежит (авторы) схема, то можно обойти необходимость ограничить, определив сначала «меньший» объект и вытянуть из этого.
Что касается «размножения объектов», вы вроде получаете это с опцией № 2 (по сравнению с # 1);что я имею в виду, все инструменты, которые я знаю, будут создавать класс для каждого именованного (глобального) сложного типа, который есть в вашем XSD;поэтому, если вам нужно иметь три типа учетных записей, у вас будет три для сценария № 1 и четыре или около того, если вы решите расширить один или несколько базовых классов;наихудший сценарий для последующего случая - когда вам нужны три специализации (конкретные, если хотите);во всяком случае, исходя из моего опыта, разница в реальных сценариях не является чем-то, что действительно могло бы так или иначе повлиять на принятие решения.
Расширение базовых типов в XML-схеме хорошо для повторного использования;однако повторное использование приносит связь;если вы анализируете это с точки зрения прямой / обратной совместимости, расширение чего-либо в базовом типе может испортить некоторые несобственные (десериализацию) XML для клиентов ваших служб, которые не хотят менятьсяих кодовая база, но вы хотите поддерживать только одну конечную точку веб-службы для всех;в этом случае стратегия прямой совместимости, основанная на xsd: any в конце композитора (xsd: sequence), станет бесполезной в первом выпуске, который идет и расширяет ваш базовый тип.
Тамеще больше;из-за этого я не думаю, что есть правильный ответ, только для тех критериев, которые вы подразумеваете, устанавливая свои плюсы и минусы.
Все мои предпочтительные варианты ниже предполагают, что вы придаете большое значение требованию обеспечить прямую / обратную совместимость ваших услуг, и вы хотите минимизировать затраты ваших клиентов на работу с вашими услугами (из-заИзменения схемы XML).
Я бы сказал, что если все ваши домены (в частности, учетные записи) могут быть полностью смоделированы (предположим, что в будущем изменений не будет) и , чтоДостаточно общности, чтобы оправдать повторное использование, затем перейдите к варианту № 2.В противном случае перейдите к варианту № 1, так как мне еще предстоит увидеть вещи, которые не меняются ...
Если моделирование вашего домена может быть выполнено на 80% или более (или какое-то число, которое вы считаете высоким) и , что существует достаточная общность, чтобы оправдать повторное использование, тогда я все равно остановился бы на варианте # 2, с оговоркой, что любые будущие расширения для общих атрибутов для учетных записей должны применяться для каждой отдельной учетной записи (в основном этоваш вариант в гибрид, сделав # 1).
Для всего остального я бы пошел # 1.Уфф, я не могу поверить, что написал все это ...