Azure Table Storage API 泛型設計
最近有機會使用到Azure Table Storage服務，Table Storage是早期Azure儲存體一種NoSQL儲存方式，程式開發上花點時間看看官網的文件，跟著範例做一下，大致上不會有太大問題。不過等真的要使用時會發現，如果按照範例程式的寫法，基本上是一整個寫死，沒有彈性可言。
建立Entity(實體)
Table Storage 的 SDK 設計是你在呼叫 Table API 之前必須傳入要儲存的 Entity(實體)，如果讀者熟悉 Entity Framework 的話，可以想成 Entity Framework 的 Entity，如官網範例的 CustomerEntity：
public class CustomerEntity : TableEntity
{
public CustomerEntity(string lastName, string firstName)
{
this.PartitionKey = lastName;
this.RowKey = firstName;
}
public CustomerEntity() { }
public string Email { get; set; }
public string PhoneNumber { get; set; }
}
然後進行CRUD操作時都是以 Entity 為單位，例如查詢：
// Create a new customer entity.
CustomerEntity customer1 = new CustomerEntity("Harp", "Walter");
customer1.Email = "Walter@contoso.com";
customer1.PhoneNumber = "425-555-0101";
// Create the TableOperation object that inserts the customer entity.
TableOperation insertOperation = TableOperation.Insert(customer1);
// Execute the insert operation.
table.Execute(insertOperation);
在正式使用碰到的問題就是，我們通常針對這類操作的 API 會先抽離出來給大家共用，但問題是，此 Table Storage API 並不會事前知道你所要操作的 Entity 格式，Entity 格式應是留給使用端去定義，這樣才能發揮 NoSQL 的長處，如果一開始定義寫死了，那就和關連式資料庫沒有差別了。
.jpg)
