This project is read-only.
  • New documentation file added 2/3/2010 (see download page)
  • This project is being used extensively with another CodePlex project - MyDistrictBuilder. You can see an implementation in action that manages massive data and supports SQL or SQL Azure migration to table storage.

Also follow other issues related on my blog site: "Larry's Clouded Mind"

Azure Table Storage Automation and Data Modeling

The code is fairly well internally documented so you should be able to follow along easily enough. It is normally my style to decorate every method and every property with documentation that is actually useful. I add enough commentary to explain why the code is there and what you might want to do with it or at least my intent when I wrote it.

This project is a fairly simple one building on the SimpleTableSample by Jim Nakashima of Microsoft. You can find his blog here:

I recommend that you get that project and watch Jim's online video if you are struggling with Azure Tables. Another good reason to use that project is to test your local environment making sure that everything is correctly setup on you local computer.

Once you are satisfied that you have a working system and that you have worked through the SimpleTableSample, you should be ready to move to the next step: working with your data model.

Working on your data model

More than likely you have something in mind that you want to put into Azure Table Storage. This article assumes that you know and understand your data model that you are trying to build. It also assumes that you don't have much of a clue how to get there from here. The intent of the code in the project is to show you how you can use Visual Studio to develop Azure projects to actually develop a working data model.

There seems to be all sorts of data modeling tools for SQL and databases in general but for Azure it is all hard labor even with the Microsoft Storage library. LINQ to SQL is of no use in Azure, the Entity Framework is HUGE! I wanted a simple way to take my existing database tables and move to Azure realizing that they are NOT the same thing and that I would have to model my data differently. That means copying my classes from other projects was pretty much out the window. But one thing my old SQL database table do have that I needed is, the columns and types. I can't go into Azure design architecture here but I assume that you basically know your tables and the columns in the tables. Because I am migrating some of my old SQL data to Azure I am retaining the key fields to assist in the migration plan. That means that I will have my partitionKey and rowKey as well as the old SQL keys.

When working with Azure it seems that because database normalization is non-existant that a one-to-one class-object with a backing Azure Table makes good sense. With judicious use of Table/partionKey/rowKey combinations and the blindeye to duplicated data one could implement a robust data storage system.

My first implementation was horrid. I had classes and files scattered all over my project trying to force it into a POCO/MVVM/Home-brew cocktail that was as sensitive as warm nitro-glycerin. Then in a light-bulb moment it occured to me that "why am I trying to put all this stuff in the same project?" Why don't I just create an assembly per Azure table and limit the exposure?

Azure Tables Implemented as Components

Vola this project. I created all the basic plumbing and effectively an API or if you are an old C++ guy a com interface (kind-of). Now my table implementation is very much like a component.

With the concept make components in mind, now came the HOW? Bing - nothing. Google - nothing. But there was Visual Studio Templates. If I could write just one component by hand then I could stamp out those bad-boys all day. It really only took a day to build test and integrate to have a working template. It has several advantages.
  • Low cost (free)
  • Easily extended
  • Not complicated (no framework)
  • Doesn't change my programming techinque or methodology

How Azure Table Components Work

If you think of a standard Visual Studio control you know that it takes properties at design-time or are settable at run-time. You also know that components expose some public memebers and some public methods. Components do their job and nothing else (Separation of concern).

So my Azure component must accept the minimum amount of inputs to make its connections to Azure while allowing the developer to actually model the data without having to know about Azure plumbing.

Basically you create connection strings in your WebRole and supply those to the Azure Component. At design-time you modify the data model class using the Visual Studio Class Diagram tool (which makes it too easy). You add your specific code implementation just as you would with any component. Finally you add your implementation code to our WebRole again like you would other components.

I probably wrote less code implementing the Azure components than I do with the typical grid control and certainly a lot faster.

Wrap up

This solution gets you running right now! It doesn't then limit you. You are completely free to extend any component as necessary - not easily done with off the shelf components.

Last edited May 13, 2011 at 3:18 PM by wph101larrya, version 5


No comments yet.