Проблема: объектыWCF объекты, множественные реализации и сериализации ошибки IList
WCF контракта не может реализовать 2 вида списков (например: список и список).
многословно объяснение:
Я строю службы WCF поверх существующей системы ядра, и я пытаюсь работать, лучший способ реализовать некоторые из своих бизнес-объектов.
Основная система использует интерфейсы для всех бизнес-объектов. Например, для управления персоналом требуется передать объект, который реализует IPerson. Здесь нет ничего необычного.
Цель состоит в том, чтобы иметь контактный объект (Лицо), который может использоваться на стороне обслуживания вещей, а также реализует IPerson, чтобы он мог быть передан в ядро, не требуя слоя преобразования. Все это отлично подходит для таких предметов, как Person.
Проблема возникает для списков: например, метод в ядре может потребовать передачи IPersonList, и, как известно, List не наследует от IList, так как любой, кто имеет дело с унаследованными генериками, знает.
В нашей действующей в настоящее время службе ASMX мы реализуем это с некоторым литьем вверх/вниз в веб-объектах. «WebPerson» наследует List и реализует IList явно, чтобы свойства IList не отображались в WSDL. не
В WCF, однако, если вы пытаетесь использовать этот же объект, вы получите следующее сообщение об ошибке:
Type 'Cssi.IBroker.Service.Cssi.Contracts.PersonList' with CollectionDataContractAttribute attribute is an invalid collection type since it has multiple definitions of interface 'IList`1'.
По-видимому, теперь, когда новый WCF сериализатору знает, как сериализовать IList, это уже не в состоянии чтобы игнорировать вторую явную реализацию.
Если возможно, я бы хотел избежать создания объекта PersonList только для контрактов, а затем преобразования в объект IPersonList и из него для каждого вызова. Изменение основной бизнес-логики для использования конкретных объектов, предназначенных только для служб WCF, не является вариантом.
Помощь!
Я должен добавить, что другой вариант, который обсуждался, заключается в том, чтобы выбросить чистый дизайн WSDL на ветру, вернуть интерфейсы в наши контракты на обслуживание и добавить атрибут ServiceKnownType к нашим контрактам. Поскольку для этой службы WCF мы будем управлять как службой, так и клиентом, это вариант, но это эффективно связывает любых будущих клиентов с использованием .Net и наших прокси-классов, поскольку наш WSDL будет бесполезен. Я бы предпочел избежать этого варианта. – mdryden