Azure Table Storage の非派生 POCO を持つことは可能ですか?
TableEntity
つまり、派生または実装しない POCO ITableEntity
?
インターフェイスまたは基本クラスに依存するモデルを持たなければならないことは、一歩後退しているように見えます。これにより、チェーンの上方への参照リークが発生するためです。別の層にモデルを設定するには、Azure Storage について知る必要があります。インターフェイスまたは基本クラス!
Azure Table Storage の非派生 POCO を持つことは可能ですか?
TableEntity
つまり、派生または実装しない POCO ITableEntity
?
インターフェイスまたは基本クラスに依存するモデルを持たなければならないことは、一歩後退しているように見えます。これにより、チェーンの上方への参照リークが発生するためです。別の層にモデルを設定するには、Azure Storage について知る必要があります。インターフェイスまたは基本クラス!
DynamicTableEntity
(ctrl+f) を見てください。エンティティのクエリと挿入に使用できます。
このタイプを使用すると、ドメイン モデルに依存関係を導入することはありませんが、自分で POCO を DynamicTableEntity に変換する必要があります。ただし、POCO にカスタム インターフェイスでフラグを立てたい場合は、このプロセスを簡単に自動化できます。マッパーを作成します(基本的に、プロパティの辞書が必要であり、パーティション/行キーが何であるかを知る必要があります)。
Azure Table Storage にエンティティを保存できない理由は、どのプロパティがパーティション キーとして機能し、どのプロパティが行キーとして機能するかを知る必要があるためです。DynamicTableEntity
「下位レベル」で作業する必要があることの利点は、リソースの消費を削減するプロパティのサブセットのみを返すクエリを作成できることです。これは、あなたの場合には有益かもしれませんし、そうでないかもしれません。
まず、次の例のように、DataServiceKey 属性を使用してクラスを装飾するという、TableEntity と ITableEntity に代わる別の方法があります。
[DataServiceKey("PartitionKey", "RowKey")]
public class MyEntity
{
public string PartitionKey {get; set;}
public string RowKey {get; set;}
public DateTime Timestamp {get; set;}
//other properties
}
ただし、Azure の実装をモデル クラスにリークさせたくないという問題は、実際には解決されません。その場合、 LOKAD Fat Entitiesのようなラッパー実装の使用を検討したいと思うかもしれません。Lokad は、モデル オブジェクトのラッパーへのシリアライズ/デシリアライズを処理し、ラッパーはテーブル ストレージに保存されます。ただし、Lokad の欠点の 1 つは、オブジェクトがストレージ内で不透明になり、 Azure Storage Explorerなどでそれらを参照できないことです。