2011-03-02 5 views
1

私はwcf rest service(4.0)への投稿要求をする必要があります。このサービスは、クライアント側のアプリケーション(jquery)とサーバー側のアプリケーション(asp.netなど)の両方から呼び出されます。 サービスは永続ストアを公開し、CRUD操作を提供します。シリアライゼーションの問題辞書<string、object> - 代替デザインオプション?

私はserialzationに問題があります。

私は数本に関連した記事読んで - WCFを消費する>http://blogs.msdn.com/b/youssefm/archive/2009/04/21/understanding-known-types.aspx

public class CustomType 
{ 
    public Dictionary<string,object> CustomObjectCollection {get; set;} 
    public SavedBy {get; set;}  
    public SavedOn {get; set;}  


    public CustomType() 
    { 
     CustomObjectCollection = new Dictionary<string,object>(); 
    } 
} 


public class State1 
{ 
    public prop1 {get; set;} 
    public prop2 {get; set;} 
} 

public class State2 
{ 
    public prop1 {get; set;} 
    public prop2 {get; set;} 
} 

クライアント:私は使用できないことがあり

public bool Save(CustomType req) 
{ 
///////// 
} 

public void save() 
{ 
    CustomType req = new CustomType(); 
    req.CustomObjectCollection("State1", new State1() {prop1 = val1, prop2 = val2 }); 
     req.CustomObjectCollection("State2", new State2() {prop1 = val3, prop2 = val4 }); 

    DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(CustomType)); 
     MemoryStream ms = new MemoryStream(); 
     serializer.WriteObject(ms, setting); 

     string json = Encoding.Default.GetString(ms.ToArray()); 
     ms.Close(); 

    Utility.HTTPRequest("http://localhost:2222/MyWCFRestSVC/save", "post", json); 

} 

WCFメソッドをこの既知のタイプは、このサービスを使用するすべてのクライアントが独自のcuを使用するため回避しますストームの種類。理想的には、サービスは、クライアントが保持したいタイプについて心配すべきではありません。このサービスは、汎用の状態情報だけを保持する永続ストアを公開していることに注意してください。

私はjson文字列表現os State1 & State2を値として格納する辞書の代わりにDictionaryを試しました。私が遭遇した問題は、DataContractJsonSerializerを使用してCustomTypeインスタンスをシリアライズすると、State1のjson文字列& State2は二重シリアル化のためにバックスラッシュ(エスケープ文字)が埋め込まれていると思いますか?

私はDataContractJsonSerializerの代わりにカスタムシリアル化について考えました。

あなたの考えを教えてください。

お時間をいただきありがとうございます。

答えて

1

サービスは明らかに意図した方法でディクショナリを使用していないため、別のデータ構造を参照する必要がありますか?

「意図したやり方で」とは、クイックルックアップを意味しています。それはハッシュテーブルです。単にクライアントアプリケーションにプッシュするだけで、たくさんの情報を集めるだけです。だからあなたが必要なのは

List<string, List<object>> 

また、あなたの "オブジェクト"もシリアル化可能であることを確認してください。

+0

ありがとうございました。私はその辞書とは関係ないと思う。私はこのプロパティを持っていても、 'public object State {get; set;} '型を知らないので、Stateプロパティを設定するためにState1型を使用すると、'既知型 'を指定せずにDataContractJsonSerializerを使用することはできませんシリアル化する情報。何かご意見は ? – StudentForever

0

もう少し前に同様の質問をしました。直接的な答えはありませんが、我々は、回避策を思い付いたん:私は過去にWCF/Webサービス上で辞書を輸送する必要があったとき

Serializing IDictionary<string, object> in WCF

+0

ありがとう、ディクショナリ<文字列、オブジェクト>を辞書<文字列、オブジェクト>にどのように置き換えたかについて詳しく説明します。また、Shivの答えに対する私の反応を見てください。 – StudentForever

+0

私はこれに関連する別の記事を追加しました:http://stackoverflow.com/questions/5171925/serializing-custom-type-with-json-string-as-property-is-adding-escape-sequences – StudentForever

+0

私はあなたがtypo - Dictionary Dictionary を配置しました。オブジェクトはすべて基本型(string、int、DateTime、string []など)でした。文字列[]オブジェクトが原因です。だから、単純なカスタムシリアライゼーションを実装しました。これは、ほとんどの型ではToString()、そして文字列[]では問題ありませんでした。 –

0

、私は一般的に辞書からサブクラス化して、IXmlSerializableインターフェイスを実装しています - すなわちReadXmlの説明()、でWriteXml()

これは、ワイヤを介したメッセージのフォーマットを制御できますと、あなたが送信されるデータの種類の知識を持っている場合は、シリアル化のより効率的な手段になります。