Jeremy S Brown

One of my favorite features of Azure is the their Table Storage Service. It allows you to store TBs of structured non-relational data in a fairly simple way. However there is one part of the service that has never set to well with me when it comes to my domain models. In order to use the service the model you are want to persist must implement the ITableEnity interface or inherit from either the TableEntity or DynamicTableEntity base classes. These classes provide the mandatory properties PartitionKey and RowKey that will serve as the Primary Key and Index for your table. Together they must be unique, and special consideration should be made for the PartitionKey since this is how Azure will partition your data within the table.

So if I have model called Contact.

If I want to use Table Storage it must become something like so:

Now you may start to see the issue I am having with this fundamental change. When I architect my projects I have a domain class library that defines all my models. On principle nothing related to data persistence is ever referenced from this project. No Entity Framework, ADO.NET, and not even Azure Storage Client Library. I am a firm believer that my domain is storage agnostic.

The solution that I came up with is to refactor my domain models as implementations of interfaces, and have the repository interfaces that I define to work against these interfaces. Normally I think domain model interfaces are overkill, but in this case it feels right. It feels more like a schema.

With the domain models now as interfaces the table storage repository class can now define a class for each domain model and have it inherit from TableEntity or DynamicTableEntity and also implement the interface for the domain model.

Now I know what you are thinking. Yes I have solved one problem but simply replaced it with another. The problem being that I am going to have to convert one model to the other as work with the repository. Not a huge problem, but an annoying one because this normally means a lot of monkey code. Code that will need to be updated each time the domain model interface has changed.

Not being a huge fan of monkey code not even from code generators I tackled this issue by creating an generic abstract class to handle this. This class makes use of a helper class that uses reflection to copy the properties. Since both the domain model and the table entity models both inherit from the same interface it makes the copying very straightforward. Here is the base class:

namespace TableStorageRepository.Entities
{
    public abstract class BaseEntity<T, U> : TableEntity
        where T : class, U, new() 
    {
        protected BaseEntity(U model)
        {
            var baseModel = model as T;
            if (baseModel != null)
            {
                SelfMap(baseModel);
            }
        }

        protected BaseEntity(U model, string partitionKey) : this(model)
        {
            this.PartitionKey = partitionKey;
        } 
        
        protected virtual void SelfMap(T source)
        {
            ModelHelper.CopyProperties(source, this);
            SetRowKey();
        }

        public virtual T ToDomainClass()
        {
            var temp = new T();
            ModelHelper.CopyProperties(this, temp);
            return temp;
        }

        protected abstract void SetRowKey();
    }
}

namespace TableStorageRepository.Entities

{

public abstract class BaseEntity<T, U> : TableEntity

where T : class, U, new()

{

protected BaseEntity(U model)

{

var baseModel = model as T;

if (baseModel != null)

{

SelfMap(baseModel);

}

protected BaseEntity(U model, string partitionKey) : this(model)

{

this.PartitionKey = partitionKey;

}

protected virtual void SelfMap(T source)

{

ModelHelper.CopyProperties(source, this);

SetRowKey();

}

public virtual T ToDomainClass()

{

var temp = new T();

ModelHelper.CopyProperties(this, temp);

return temp;

}

protected abstract void SetRowKey();

}

In the BaseEntity class the generic T is the domain model class, and U is the interface implemented by the domain model. By providing both this allows for the constraint to be defined to ensure that T is a class, inherits from the domain interface and has parameter less constructor. To define our ContactEntity class it would look like this:

namespace TableStorageRepository.Entities
{
    public class ContactEntity : BaseEntity<Contact, IContact>, IContact
    {
        public ContactEntity():base(null)
        {
            
        }

        public ContactEntity(IContact model) : base(model)
        {
        }

        public ContactEntity(IContact model, string partitionKey) : base(model, partitionKey)
        {
        }

        protected override void SetRowKey()
        {
            RowKey = string.Format("Contact_{0}", Id);
        }

        public Guid Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string EmailAddress { get; set; }
        public DateTime DateCreated { get; set; }
        public bool Active { get; set; }
    }
}

namespace TableStorageRepository.Entities

{

public class ContactEntity : BaseEntity<Contact, IContact>, IContact

{

public ContactEntity():base(null)

{

}

public ContactEntity(IContact model) : base(model)

{

}

public ContactEntity(IContact model, string partitionKey) : base(model, partitionKey)

{

}

protected override void SetRowKey()

{

RowKey = string.Format("Contact_{0}", Id);

}

public Guid Id { get; set; }

public string FirstName { get; set; }

public string LastName { get; set; }

public string EmailAddress { get; set; }

public DateTime DateCreated { get; set; }

public bool Active { get; set; }

}

The next step would be to implement the interface and since the interface is all properties Visual Studio helps you take care of that quickly.

Table Storage also requires that all table entities must have a parameter less constructor. This is the storage library can serialize and deserialize table entity classes. In my example the constructor just passes a null to the base class.

The only other item that would need to be implemented would be the abstract method SetRowKey. The reason it is abstract is to allow flexibility on how each table entity’s RowKey is set. In the case of our ContactEntity you can set the RowKey to the Id of the domain model since it is a Guid. I normally use a prefix of the model type since Table Storage allows for multiple entities to be stored in a single table. This helps with querying later. The important thing is that the RowKey is unique within the Partition it is associated with. In the case of my base class the PartitionKey is set in the constructor. The reason being that I works for how I want my repository classes to function. There is no reason why it couldn’t also be handled a different way.

With our ContactEntity implemented the repository can easily accept our domain model, convert it to its table entity counterpart, and save it to the cloud. Retrieval is just as straightforward. The key thing being that the domain model is preserved and the mechanics of using Azure Table Storage are cleanly encapsulated within the repository. If the domain was to evolve to the point that table storage was no longer a good fit the transition to the new storage will not have to worry with any tightly coupled elements of Azure Table Storage. Just implement the repository interfaces for the new storage, and life will be good.

The demo project for this post can be found on GitHub.
Microsoft Azure SDK 2.5 or greater is required. Table storage is setup to use local development enviroment.

My first publication!

Note to Self: When Deploying a Web API project to Azure that references an F# project

Azure Table Storage Repository