Использование пользовательских объектов между веб-службами

Question

У меня есть веб-сервис, который предназначен для приема данных о производительности через пользовательский объект. Пользовательский объект содержит Сбор (Общий список) показателей эффективности среди других данных. Показатель производительности состоит из простых типов данных (строки, ints и datetime). Единственный метод, предоставляемый веб-сервисом, требует, чтобы этот пользовательский объект (объект данных производительности) был передан.

Проблема заключается в использовании этого настраиваемого объекта извне. Я хочу использовать методы Add() и Item() класса Generic List вместе с различными другими функциями этого класса в другом веб-сервисе. Если я запрашиваю объект из Web-сервиса Performance Data, он серализует внутреннюю коллекцию в arrayList. Я бы хотел, чтобы он оставался универсальной коллекцией.

Я играл с использованием метода XmlInclude, но в настоящее время havent нашел решение с ним.

Следующее, что я попытался сделать, это создать сборку этого конкретного объекта, которую могут использовать веб-служба Peformance Data, и любые спутниковые программы (т. Е. Другой веб-сервис). Проблема здесь в том, что когда я пытаюсь передать в пользовательский объект, созданный отдельной сборкой, веб-сервисы производительности передают его другим типом. (Также я применяю атрибут XmlInclude (GetType (пользовательская сборка)) для открытого метода). Однако все же считается, что типы не могут быть конвертируемыми.

Примечание. Я бы предпочел назвать Performance Data WS для получения пользовательского объекта вместо того, чтобы иметь дело с добавлением сборок в каждый проект, которому нужен доступ.

У кого-нибудь есть идея, отличная от реструктуризации программы для работы с методами, открытыми ArrayList?

Answer 1

Если вы используете WCF, вы можете настроить тип сбора, будь то ArrayList, фиксированный массив или общий список.

Answer 2

Я нашел решение, которое будет работать с .Net 2.0. При первом использовании контракта с веб-службами (WSCF http://www.thinktecture.com/resourcearchive/tools-and-software/wscf/wscf-walkthrough) Мне удалось передать общие коллекции между двумя службами. Нижняя сторона WSCF, как следует из названия, заключается в том, что подход требует использования контракта-сначала, а не более общей методологии первого кода. К счастью, не сложно изменить класс и прокси после их создания. Надеюсь, это поможет любому потерянному путешественнику ...