Должен ли я * использовать * ObservableCollection в WCF-клиенте Silverlight?

Question

При доступе к Silverlight в WCF вы получаете прокси, сгенерированные с помощью ObservableCollection

Прекрасно, когда вы привязываете данные, но немного неуклюже, когда вы просто вызываете метод. Например, следующий метод обслуживания:

    [OperationContract]
    public SearchOrdersMsgOut SearchOrders(ShippingStatusType[] shippingStatuses,
                                           string[] orderId)
    {
    }

генерируется с ObservableCollection. Какие! Они просто параметры. Зачем мне когда-нибудь их «наблюдать»?

Я в порядке, если у меня есть , чтобы сделать это - но, похоже, должен быть способ заставить простые структуры массива, когда я знаю, что никогда не привязываю данные - особенно для входных сообщений. *

Я бы предпочел сделать это:

 searchCriteria.PaymentStatus = new [] { PaymentStatusType.PaymentFailed, PaymentStatusType.Unpaid };               

чем это:

 searchCriteria.PaymentStatus = new ObservableCollection<PaymentStatusType> { PaymentStatusType.PaymentFailed, PaymentStatusType.Unpaid };

Есть ли способ?

PS. Я действительно использую объект SearchCriteria для своих критериев поиска, но я упростил для этого примера вопрос о том, обрабатывались ли параметры по-разному.

Answer 1

Вы можете сделать это для всей службы, но не для каждого метода. В диалоговом окне «Добавить ссылку на службу» нажмите «Дополнительно» и выберите «System.Array» для типа «Коллекция». Но я не знаю ни одного способа сделать это по методу, то есть использовать массив для одних методов и ObservableCollection для других.

Answer 2

Еще одна вещь, которую нужно проверить (если вы хотите ObservableCollection<T>, но вы получаете T[]) - это файл Reference.svcmap

Убедитесь, что вы включили «System.Windows» в имя типа.

  <CollectionMapping TypeName="System.Collections.ObjectModel.ObservableCollection`1, System.Windows" Category="List" />

а не

  <CollectionMapping TypeName="System.Collections.ObjectModel.ObservableCollection`1" Category="List" />

Полагаю, возможно, он не может найти Dll и по умолчанию []

Answer 3

Закончилось возникновение проблемы OPPOSITE, когда VS2010 RC имел ошибку, не позволяющую ему генерировать ObservableCollections.

К счастью есть два обходных пути :

Вариант 1: Поверьте, лучший вариант - это обновить файл «Reference.svcmap» для ссылки на затронутую службу. В обозревателе решений выберите «показать все файлы» и разверните затронутый ссылочный узел. Там вы найдете файл «Reference.svcmap», дважды щелкните, чтобы открыть в редакторе. Для отображения наблюдаемой коллекции вы должны увидеть что-то вроде этого:

 <CollectionMapping TypeName="System.Collections.ObjectModel.ObservableCollection`1" Category="List" />

Измените значение TypeName, чтобы включить сборку Silverlight «System.Windows» - как показано ниже:

 <CollectionMapping TypeName="System.Collections.ObjectModel.ObservableCollection`1, System.Windows" Category="List" />

Вариант 2 : Генерация вашего Ссылка на сервис Reference.vb / .cs файлы прокси-кода вне VS используя напрямую SLSvcUtil.exe. пример запуска инструмента через командную строку где это будет адресовано код выпуска наблюдаемой коллекции проблема генерации: "C: \ Program Files (X86) \ Microsoft SDKs \ Silverlight \ v3.0 \ Tools \ SlSvcUtil.exe» / r: "C: \ Program Files (x86) \ Microsoft Silverlight \ 3.0.40818.0 \ System.Windows.dll» /ct:System.Collections.ObjectModel.ObservableCollection`1 Http: ///Service1.svc Это будет по умолчанию генерировать C # версия вашей справочной службы код прокси. Если вам нужно сгенерировать VB версия, вы можете передать Переключатель «/ Language: VB».

Answer 4

Хорошо, вот странный поворот после того, как вы привыкли использовать ObservableCollection для моих клиентов Silverlight.

Я попытался вернуть Linq2XSD объект из моей службы WCF, а затем внезапно опустился и вот он изменил все свойства ObservableCollection<T> в простые массивы [].

Я думал, что это что-то особенное для Linq2XSD - поэтому я попытался просто добавить простое свойство XTypedElement в определение сервиса:

    public XTypedElement[] PipelineLogs { get; set; }

Это вызывает [] вместо ObservableCollection<T> в сгенерированном прокси - где обычно string[] становится ObservableCollection<string>.

Не спрашивайте меня, почему!

С тех пор я удалил его, потому что на самом деле предпочитаю ObservableCollection<T>. Я просто подумал, что наблюдение может заинтересовать кого-то с подобной проблемой - особенно если кто-то может объяснить, почему он это делает!