RIA服務傳遞複雜對象作爲參數傳遞給查詢域名服務方法

我遇到類似this thread規定的問題的一些困難與WCF RIA服務。RIA服務傳遞複雜對象作爲參數傳遞給查詢域名服務方法

的方法的DomainService我創建（查詢方法）應該採取一個複雜的對象參數。示例的DomainService方法：

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

參數對象：

public class ComplexObjectParameter 
{   

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

    ... other fields 
}

我得到這個編譯錯誤：錯誤70參數域操作條目「GetComplexObject」的「測試」必須是預定義的序列化的一個類型。

在網絡上經過一番搜索，我發現this msdn thread。它聲明這是RIA服務的一個限制，並且該線程沒有指出體面的解決方法。

現在似乎有一些骯髒的解決方法：

更改複雜的參數輸入字符串和序列化/反序列化parameterobject我們自己，我發現一個很哈克的解決方案。
使用[調用]在域服務方法和寬鬆的所有RIA跟蹤功能，我首先使用RIA爲其標籤。

上述解決方案是否有替代方案具有更少的缺點？是否有人找到了解決此問題的更優雅的解決方法？

由於

來源

2010-08-19 Stephane

我和你的第二個選項Stephane一起去了。我返回的複雜類型在客戶端上是隻讀的，所以丟失跟蹤功能對我來說不是問題。下一次考慮將可能的解決方案（即使是骯髒的解決方案）放入答案中...我會投票選出問題和答案！ – 2011-07-20 00:04:58

髒解決方法3，是使用[調用]屬性，並添加一個方法到域服務以暴露「複合型」，它通知WCF RIA工具來在客戶機上創建實體-side：

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

我在我的域服務方法中放入NotSupportedException，以防止靜默失敗，如果該方法是遠程調用的。

我不確定此解決方案如何影響丟失「所有RIA跟蹤功能」的問題。它不回答如何使用複雜類型作爲參數來創建可組合的查詢。

這是骯髒的，但最近抽象問題的問題根源。呼叫和接收代碼更清潔。這在保持較高水平的「優雅」的同時推動了骯髒的下降。

來源

2010-08-23 19:02:16

嗨，埃德，我已經創建了一個假的查詢方法，以在客戶端生成複雜的參數對象。它是髒解決方案2的一部分。但是我最終還是使用了另一種解決方案：將複雜的對象參數保存到數據庫中，然後在查詢時傳遞該ID。這種解決方案可能不適用於所有遇到此問題的人，但它適合我的情況。謝謝你的努力。 – Stephane 2010-08-24 07:09:51

一個解釋說你需要'暴露'複雜類型的投票。 – 2011-07-20 00:10:28

超級老問題，我知道了。但我剛剛得到了這一點，並找到了答案。來自ComplexObject上的MSDN Docs：

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.

來源

2011-12-13 01:50:32 rossipedia

RIA服務傳遞複雜對象作爲參數傳遞給查詢域名服務方法

回答

相關問題