2

オンライン サービス (Azure Web サービス) に対する小さな WinRT クライアント アプリがあります。サーバーは JSON でエンコードされたオブジェクトを (潜在的な追加のメタデータと共に) クライアントに送信します。クライアントの責任は、このデータを適切にクラスに逆シリアル化し、適切なハンドラーに転送することです。

現在、受け取ったオブジェクトは単純な方法で逆シリアル化できます。

TodoItem todo = JsonConvert.DeserializeObject<TodoItem>(message.Content);

ただし、複数の種類のアイテムを受け取ることができます。そこで、現在考えていることは次のとおりです。

  1. 「Content-Object: TodoItem」のように、サーバー側のヘッダーに型情報を含めます。
  2. クライアント側で TodoItem に属性を定義します (以下を参照)
  3. サーバーからメッセージを受信すると、定義した属性を使用してクラスを見つけます。
  4. 解決された型で逆シリアル化メソッドを呼び出します

(2.で述べた属性の例)

[BackendObjectType="TodoItem"]
public class TodoItem

ただし、このアプローチに関する私の問題は、呼び出すことができないため、逆シリアル化の Type to Generics です。

Type t = ResolveType(message);
JsonConvert.DeserializeObject<t>(message.Content);

これに対するいくつかの解決策を見つけて、DeserializeObject のメソッド情報を取得し、リフレクションを使用してそれを呼び出すことを試みました。ただし、GetMethod() は WinRT には存在せず、DeserializeObject のジェネリック バージョンを取得するために使用できる代替手段を見つけることができませんでした (名前でフェッチすると非ジェネリック オーバーロードが得られるため)。リフレクションと GetMethod を使用してもかまいません。メソッドをキャッシュ (?) し、メッセージを受信するたびにメソッドを呼び出すことができるので、毎回解決する必要はありません。

では、どうすれば後半を達成できますか、および/またはこれにアプローチする別の方法はありますか?

4

3 に答える 3

2

わかりました。メソッドの DeserializeObject(string, Type, JsonSerializerSettings) オーバーロードを発見したので、これは最初からまったく問題ではなかったように感じます。それは見事に機能します。ただし、アプローチに関するフィードバックを引き続きお聞きしたいと思います。型名を解決する方法として属性を使用することは合理的だと思いますか、それとももっと良い方法はありますか? ただし、クラス名を直接使用したくはありません。中間者が何かを初期化できるリスクを冒したくないからです。

于 2013-07-19T12:20:49.280 に答える
0

ほんの数分前に、あなたが望むことを行う別の方法を投稿しました。こちらをご覧ください。ご不明な点がございましたら、お気軽にお問い合わせください。

JSONの逆シリアル化の問題

于 2013-07-19T12:19:05.747 に答える
0

これを試して

http://json2csharp.com/

Json 文字列をここに配置すると、クラスが生成されます

それから

 public static T DeserializeFromJson<T>(string json)
    {
        T deserializedProduct = JsonConvert.DeserializeObject<T>(json);
        return deserializedProduct;
    }

 var container = DeserializeFromJson<ClassName>(JsonString);
于 2013-07-19T12:22:33.987 に答える