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 的長處,如果一開始定義寫死了,那就和關連式資料庫沒有差別了。