4

次のようなエンティティをテーブル ストレージに使用したいと思います。

public class MyEntity
{
    public String Text { get; private set; }
    public Int32 SomeValue { get; private set; }

    public MyEntity(String text, Int32 someValue)
    {
        Text = text;
        SomeValue = someValue;
    }
}

しかし、ATS が必要なので、それは不可能です。

  1. パラメーターなしのコンストラクター
  2. すべてのプロパティは公開されており、読み取り/書き込み可能です。
  3. TableServiceEntity から継承します。

最初の 2 つは、私がやりたくないことです。読み取り専用であるべきデータを誰でも変更できるようにする必要があるのはなぜですか? または、この種のオブジェクトを一貫性のない方法で作成するか (.ctor とは何ですか?)、最悪の場合は、PartitionKey または RowKey を変更します。これらのデシリアライゼーション要件によってまだ制約を受けているのはなぜですか?

そのような方法でソフトウェアを開発するのは好きではありません。オブジェクトを自分でシリアル化および逆シリアル化できる方法でテーブル ストレージ ライブラリを使用するにはどうすればよいですか? オブジェクトが TableServiceEntity から継承されている限り、問題にはならないと思います。

これまでのところ、オブジェクトを保存する必要がありましたが、それを取得する方法がわかりません:

            Message m = new Message("message XXXXXXXXXXXXX");

            CloudTableClient tableClient = account.CreateCloudTableClient();
            tableClient.CreateTableIfNotExist("Messages");
            TableServiceContext tcontext = new TableServiceContext(account.TableEndpoint.AbsoluteUri, account.Credentials);

            var list = tableClient.ListTables().ToArray();

            tcontext.AddObject("Messages", m);
            tcontext.SaveChanges();

これらの逆シリアル化の要件を回避したり、生のオブジェクトを取得したりする方法はありますか?

乾杯。

4

5 に答える 5

5

ストレージ クライアント ライブラリを使用する場合は、はい、保存するオブジェクトに対してできることとできないことに制限があります。ポイント1は正しいです。ポイント2を拡張して、「保存するすべてのプロパティはパブリックで読み取り/書き込み可能である必要があります」（整数プロパティの場合、読み取り専用プロパティを使用することで回避でき、保存しようとしません）しかし、あなたはしませんから継承する必要はありませんTableServiceEntity。

TableServiceEntityプロパティ PartitionKey、RowKey、Timestamp を持ち、DataServiceKey属性で装飾された非常に軽いクラスです (Reflector を見てください)。自分で作成し、TableServiceEntity から継承しないクラスに対して実行できるこれらすべてのこと (これらのプロパティの大文字と小文字が重要であることに注意してください)。

それでもクラスの作成方法を十分に制御できない場合は、いつでもストレージ クライアント ライブラリを無視して、REST APIを直接使用することができます。これにより、XML を任意の方法でシリアライズおよびデシリアライズすることができます。LINQ でクエリを作成する機能など、ライブラリの使用に伴う優れた機能がすべて失われます。

于 2011-02-13T19:59:28.180 に答える
4

Table Storage の ADO.NET ラッパーに関する制約は、確かにやや苦痛です。Lokad.Cloudに実装されているFat Entityアプローチを採用することもできます。これにより、エンティティのシリアル化に関する柔軟性が大幅に向上します。

于 2011-02-14T14:06:01.500 に答える
2

継承を使用しないでください。

独自の POCO を使用する場合は、必要に応じてクラスを作成し、pK と rK を保持し、シリアル化されたバイト配列としてクラスを運ぶ別の tableEntity ラッパー/コンテナー クラスを作成します。

于 2011-02-14T01:11:00.927 に答える
1

あなたはあなたが望むものを達成するために作曲を使うことができます。ストレージに必要なテーブルエンティティを作成し、残りのアプリケーションコードに表示させたいAPIを提供するもののラッパーとしてPOCOを作成します。より良いコードのためにいくつかのインターフェースを混ぜることさえできます。

于 2011-06-09T23:23:50.817 に答える
1

System.Reflection.Emit http://blog.kloud.com.au/2012/09/30/a-better-dynamic-tableserviceentity/を使用して実行時に POCO ラッパーを生成する方法はどうですか

于 2012-10-01T12:10:07.653 に答える