Non-derived POCO and Azure Storage

问题

Is it possible to have a non-derived POCO for Azure Table Storage?

In other words, a POCO that does not derive from TableEntity or implement ITableEntity?

It seems a step backward to have to have a model which is dependent on the interface or base class, as this causes reference leaks upward in the chain - I cannot set up the model in another tier without it having to know about Azure Storage for either the interface or the base class!

回答1:

Take a look at DynamicTableEntity (ctrl+f for it). It can be used to query and insert entities.

Using this type, you won't introduce any dependencies intor your Domain Model, however you will have to convert a POCO to a DynamicTableEntity by yourself – this process can easily be automated though if you're willing to flag your POCOs with a custom interface and write a mapper (basically you just need a dictionary of properties + need to know wich ones are Partition/RowKey).

The reason why you can't just save any entity in Azure Table Storage is that it needs to know which property acts as Partition Key and wich as Row Key. The upside of having to work with DynamicTableEntity on a "lower level" is that you can create queries that return only a subset of properties which reduces resource consumption. This may or may not be beneficial in your case.

回答2:

Have a look at the package I implemented and put in Nuget: https://www.nuget.org/packages/ObjectFlattenerRecomposer/

It is also being added into Azure Storage SDK next version: https://github.com/Azure/azure-storage-net/pull/337/files

Description:

Provides functionality to flatten complex objects into EntityProperty dictionary and functionality to recompose original complex object from the flattened property dictionary. One usage is that the API allows writing any complex object with nested properties into Azure Table Storage in flattened form which is not normally possible by using the Azure Storage Client SDK.

The version 2.0 now also supports writing and reading IEnumerable type properties like Lists, Arrays, Dictionaries to Azure Table Storage.

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

Usage:

//Flatten object and convert it to EntityProperty Dictionary

Dictionary<string, EntityProperty> flattenedProperties = ObjectFlattenerRecomposer.Flatten(complexObject);

// Create a DynamicTableEntity and set its PK and RK
DynamicTableEntity dynamicTableEntity = new DynamicTableEntity(partitionKey, rowKey);

dynamicTableEntity.Properties = flattenedProperties;

// Write the DynammicTableEntity to Azure Table Storage using client SDK

//Read the entity back from AzureTableStorage as DynamicTableEntity using the same PK and RK
DynamicTableEntity entity = [Read from Azure using the PK and RK];

//Convert the DynamicTableEntity back to original complex object.
Imagine original complexObject was of type Order.

Order order = ObjectFlattenerRecomposer.ConvertBack<Order>(entity.Properties);

回答3:

First, there is another alternative to TableEntity and ITableEntity, which is to use DataServiceKey attribute to decorate your class, as in the following example:

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

However, that doesn't really solve your problem of not wanting to leak Azure implementation into your model class. In which case I think you might want to look at using a wrapper implementation like LOKAD Fat Entities . Lokad will handle serialization/deserialization of your model object into a wrapper that is in turn stored in table storage. One downside to Lokad, however, is that your objects become opaque in storage and you can't browse them with something like Azure Storage Explorer.

来源：https://stackoverflow.com/questions/15685457/non-derived-poco-and-azure-storage

标签

azure-table-storage