Nicht-abgeleitete POCO- und Azure-Speicher

Question

Ist es möglich, eine nicht abgeleitete POCO für Azure Table Storage zu haben?

Mit anderen Worten, ein POCO, das nicht von TableEntity abgeleitet ist oder implementieren ITableEntity?

Es scheint ein Schritt rückwärts zu sein, um ein Modell zu haben, das von der Schnittstelle oder Basisklasse abhängig ist, da dies Referenzlecks nach oben in der Kette verursacht - ich kann das Modell nicht in einer anderen Ebene aufbauen, ohne es kennen zu müssen Azure Storage für die Schnittstelle oder die Basisklasse!

Answer 1

Werfen Sie einen Blick auf DynamicTableEntity (Strg + F dafür). Es kann verwendet werden, um Entitäten abzufragen und einzufügen.

Mit diesem Typ werden Sie keine Abhängigkeiten in Ihrem Domänenmodell einführen, jedoch müssen Sie einen POCO selbst in einen DynamicTableEntity konvertieren - dieser Prozess kann jedoch leicht automatisiert werden, wenn Sie Ihre POCOs kennzeichnen möchten mit einer benutzerdefinierten Schnittstelle und schreiben Sie einen Mapper (im Grunde brauchen Sie nur ein Wörterbuch von Eigenschaften + müssen wissen, welche sind Partition/RowKey).

Der Grund, warum Sie nicht einfach eine Entität in Azure Table Storage speichern können, ist, dass sie wissen muss, welche Eigenschaft als Partitionsschlüssel und welche als Zeilenschlüssel fungiert. Der Vorteil der Arbeit mit DynamicTableEntity auf einer "niedrigeren Ebene" besteht darin, dass Sie Abfragen erstellen können, die nur eine Teilmenge von Eigenschaften zurückgeben, wodurch der Ressourcenverbrauch reduziert wird. Dies kann in Ihrem Fall von Vorteil sein oder auch nicht.

Answer 2

Erstens gibt es eine weitere Alternative zu TableEntity und ITableEntity, die DataServiceKey Attribut zu verwenden, ist Ihre Klasse zu dekorieren, wie im folgenden Beispiel:

[DataServiceKey("PartitionKey", "RowKey")] 
public class MyEntity 
{ 
    public string PartitionKey {get; set;} 
    public string RowKey {get; set;} 
    public DateTime Timestamp {get; set;} 
    //other properties 
} 

jedoch, die nicht wirklich lösen nicht das Problem der Sie möchten die Azure-Implementierung nicht in Ihre Modellklasse verlagern. In diesem Fall denke ich, dass Sie vielleicht eine Wrapper-Implementierung wie LOKAD Fat Entities verwenden möchten. Lokad wird die Serialisierung/Deserialisierung Ihres Modellobjekts in einen Wrapper übernehmen, der wiederum im Tabellenspeicher gespeichert wird. Ein Nachteil von Lokad ist jedoch, dass Ihre Objekte im Speicher undurchsichtig werden und Sie sie nicht mit etwas wie Azure Storage Explorer durchsuchen können.

Answer 3

Werfen Sie einen Blick auf das Paket I und in Nuget setzen umgesetzt: https://github.com/Azure/azure-storage-net/pull/337/files

Beschreibung:

Bietet Funktionalität https://www.nuget.org/packages/ObjectFlattenerRecomposer/

Es ist auch nächste Version in Azure Storage SDK hinzugefügt werden wird Reduzieren Sie komplexe Objekte in das EntityProperty-Dictionary und die Funktionalität, um das ursprüngliche komplexe Objekt aus dem reduzierten Eigenschaftenwörterbuch zusammenzusetzen. Eine Verwendung besteht darin, dass die API das Schreiben beliebiger komplexer Objekte mit geschachtelten Eigenschaften in Azure Table Storage in einer vereinfachten Form ermöglicht, was normalerweise mit dem Azure Storage Client SDK nicht möglich ist.

Die Version 2.0 unterstützt jetzt auch das Schreiben und Lesen von IEnumerable Typeigenschaften wie Listen, Arrays, Wörterbücher in Azure Table Storage.

Blog: https://doguarslan.wordpress.com/2016/02/03/writing-complex-objects-to-azure-table-storage/

Verbrauch: // Objekt Flatten und wandeln es in EntityProperty Wörterbuch

Wörterbuch flattenedProperties = ObjectFlattenerRecomposer.Flatten (complexObject);

// Erstellen Sie eine DynamicTableEntity, und legen Sie ihre PK und RK fest DynamicTableEntity dynamicTableEntity = new DynamicTableEntity (partitionKey, rowKey);

dynamicTableEntity.Properties = flatternedProperties;

// Schreiben Sie die DynammicTableEntity zu Azure Tabellen Speicher mit Client SDK

// das Unternehmen von AzureTableStorage als DynamicTableEntity Lesen wieder die gleiche PK und RK mit DynamicTableEntity entity = [Lesen von Azure die PK und RK mit] ;

// Konvertieren Sie die DynamicTableEntity zurück in das ursprüngliche komplexe Objekt. Stellen Sie sich vor, dass das ursprüngliche complexObject vom Typ Order ist.

Reihenfolge der Bestellung = ObjectFlattenerRecomposer.ConvertBack (entity.Properties);