Ria Services Passing Complex Object as parameter to a query domain service method

Question

I'm experiencing some difficulties with a WCF RIA Services similar to the problem specified in this thread.

The domainservice method I'm creating (a Query method) should take a complex object parameter. example domainservice method:

public ComplexObjectResult GetComplexObject(ComplexObjectParameter test)
   {
        //do stuff
   }

the parameter object:

public class ComplexObjectParameter 
{        

    [Key]
    public decimal ID { get; set; }

    ... other fields
}

I get this compilation error: Error 70 Parameter 'test' of domain operation entry 'GetComplexObject' must be one of the predefined serializable types.

After some searching on the web I found this msdn thread. It states that this is a limitation of RIA services and the thread specifies no decent workarounds.

Now there seem to be some dirty workarounds:

• Change the complex parameter to type string and Serialize/Deserialize the parameterobject ourself which I find a very hacky solution.

• Use [Invoke] tag on the domain service method and loose all RIA tracking functionality, for which I am using RIA in the first place.

Are there alternatives for the mentioned solutions that have less disadvantages? Has someone found a more elegant workaround for this problem?

Thanks

Answer 1

Dirty workaround three, is to use the [Invoke] attribute and add a method to the domain service to expose the "complex type", which informs the WCF RIA tooling to create the entity on the client-side:

public ComplexObjectParameter ExposeComplexObjectParameter()
{
    throw new NotSupportedException();
}

I put NotSupportedException in my domain service methods to prevent silent failures if the method is ever called remotely.

I'm not sure about how this solution affects the issue of losing "all RIA tracking functionality". It does not answer how to create a composable query using a complex type as a parameter.

It's dirty, but abstracts the problem closest to the source of problem. The calling and receiving code is cleaner. This maintains the "elegance" at the higher level while pushing the dirty down.

Answer 2

Super old question, I know. But I just got bit by this, and found an answer. From the MSDN Docs on ComplexObject:

But a ComplexObject differs from an Entity in important ways. In particular, complex types do not have identities. This means that they do not have members marked with the KeyAttribute and so clients cannot do identity caching for them as it does for entities. Complex types cannot be shared or referenced from multiple parent instances and they do not support inheritance.