AzureTableDataStore supports POCO classes with a few special characteristics to make note of. So let's have a look at a few examples:

public class MyLittleEntity
{
    [TableRowKey]
    public string MyEntityId { get; set; }
    [TablePartitionKey]
    public string MyEntityPartitionKey { get; set; }

    public string MyStringValue { get; set; }
    public List<string> MyListOfStrings { get; set; }
    public DateTime MyDate { get; set; }
    public Guid MyGuid { get; set; }
    public long MyLong { get; set; }
    public int MyInt { get; set; }
    public byte[] MyBytes { get; set; }
    public EntitySubClass MySubClass { get; set; }
    public Dictionary<string, EntitySubClass> MyDictionaryOfSubClasses { get; set; }
    public LargeBlob MyLargeBlob { get; set; }
}

public class EntitySubClass
{
    public string MyValue { get; set; }
}

This is a valid model that serializes and deserializes just fine. A few things to note here:

• The table RowKey and PartitionKey of the entity have been defined here using the TableRowKey and TablePartitionKey attributes. This is one way of doing it. You could leave them out and specify the properties that act as RowKey and PartitionKey in the TableDataStore<MyLittleEntity> constructor if you wish to keep your entity model clean.
• When a property is set as Row/PartitionKey it is stored in the table in the RowKey/PartitionKey fields. It is not duplicated as a field. The TableDataStore client will handle the serialization and deserialization to/from the RowKey and PartitionKey table fields to the correct properties in the entity data model.
• The standard data types that Azure Table Storage supports are naturally supported (listed in MSFT docs here)
• Deep structures are supported: you can have properties that are classes, which inside them have properties that are classes and so on.
• In addition to standard types, collections are also supported: List<T> and Dictionary<T> have been tested, and whatever Newtonsoft.Json supports should be supported here as well. In practice these are serialized into JSON and stored as a string in the table row.
• The special LargeBlob class represents blobs stored in a linked Azure Blob Storage container, more on that under LargeBlobs.

The Azure Table Storage limitations still apply, which in short are:

• A table entity may not have more than 255 properties in total (RowKey + PartitionKey + Timestamp + 252 other properties)
• Serialized form of entity property name must not exceed 255 characters
• The size of a single entity may not exceed 1 MB
• Partition and Row Keys may not exceed 1024 chars and may not contain control characters
• Property size may not exceed 65536 bytes
• DateTime values must be between 1601-01-01 and 9999-12-31

Note that you may also run into stricter limitations when testing with Azure Storage Emulator - these are not accounted for.

In addition, you cannot have collections that contain LargeBlob properties. That is not supported.

Due to the way that the LargeBlob blobs are stored in Blob storage, the blob path and file name have some limitations:

• Blob path cannot exceed 1024 characters (with LargeBlobs note that table name, partition and row keys are included in the blob path)
• Blob filename should not end with / or . characters

• PartitionKey and RowKey are reserved property names that should not be in the entity, unless they really are the PartitionKey and RowKey. Stating that a property is RowKey using the TableRowKey attribute for example, and then having an additional RowKey property in the model will cause issues.
• Timestamp is also a reserved property, and should never be used.