У меня возникли некоторые трудности со службами RIA WCF, аналогичные проблеме, указанной в этой теме .
Метод доменной службы I ' Пример метода службы домена:
public ComplexObjectResult GetComplexObject(ComplexObjectParameter test)
{
//do stuff
}
объект параметра:
public class ComplexObjectParameter
{
[Key]
public decimal ID { get; set; }
... other fields
}
Я получаю эту ошибку компиляции: Ошибка 70 Параметр 'test' записи операции домена 'GetComplexObject' должен быть одним из предопределенных сериализуемых типов .
После некоторых поисков в Интернете я нашел эту ветку msdn . В нем говорится, что это ограничение служб RIA, и поток не определяет достойных обходных путей.
Теперь, по-видимому, есть некоторые грязные обходные пути:
Измените комплексный параметр на строку типа и выполните сериализацию / десериализацию объектаобъекта, который я сам нахожу. очень хакерское решение.
Используйте метку [Invoke] в методе доменной службы и потеряйте все функции отслеживания RIA, для которых я в первую очередь использую RIA.
Существуют ли альтернативы для упомянутых решений, которые имеют меньше недостатков? Кто-то нашел более элегантное решение этой проблемы?
Спасибо
Третий грязный обходной путь заключается в использовании атрибута [Invoke] и добавлении метода в службу домена для раскрытия «сложного типа», который сообщает инструментам WCF RIA о создании объекта на стороне клиента:
public ComplexObjectParameter ExposeComplexObjectParameter()
{
throw new NotSupportedException();
}
Я помещаю NotSupportedException в свои методы службы домена, чтобы предотвратить автоматические сбои, если метод когда-либо вызывается удаленно.
Я не уверен, как это решение влияет на проблему потери «всех функций отслеживания RIA». Он не отвечает на вопрос, как создать составной запрос с использованием сложного типа в качестве параметра.
Это грязно, но абстрагируется от проблемы, наиболее близкой к источнику проблемы. Код вызова и приема чище. Это поддерживает «элегантность» на более высоком уровне, выталкивая грязь вниз.