Azure Table Storage API 泛型設計

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

Visual Studio裡偽前端開發神器Reload,讓你也擁有即開發即所見功能

Visual Studio裡偽前端開發神器Reload,讓你也擁有即開發即所見功能

好早以前,我介紹過在Sublime Text 3下的「前端開發神器 - Emmet LiveStyle 」,前端還有另一套有名的LiveReload都是很棒即開發即所見的開發方式。難到我們寫伺服器端的開發人員們,只能看著前端耍炫、耍酷、流著口水羨慕嗎?

.NET Framework 4.6新增Unix TimeStamp方法

.NET Framework 4.6新增Unix Time Stamp

skilltree課程

Timestamp(中文稱時戳、時間戳)是經常用於安全保護上的一種機制,例如每天上下班的打卡,就是一種保護勞資雙方的機制,卡打下去的那一刻的時間點是無法被偽造,用計算工時與工資。在網站資訊安全方面,例如近年流行的OAuth認證機制(facebook登入、google登入、github登入、Microsoft account登入…等第三方登入機制)中重要的Token,通常就會帶有Timestamp機制,以驗證Token的時效性。

Unix Time Stamp

TimeStamp很好,但他的格式並不好處理,我們看一下wiki上的範例:

  • Tue 01-01-2009 6:00
  • 2005-10-30 T 10:45 UTC
  • 2007-11-09 T 11:20 UTC
  • Sat Jul 23 02:16:57 2005
  • 12569537329
  • (1969-07-21 T 02:56 UTC) – first footstep on the Moon, "That's one small step for man, one giant leap for mankind"
  • 07:38, 11 December 2012 (UTC)

TimeStamp格式那麼多之外,在多國語系下,你可能還要自行先轉換為UTC (格林威治標準時間)時間。

在上述格式中,我們特別注意到一個12569537329數值,這是什麼東西?這種格式稱Unix Time,它是一種把時間轉換為數值的方式,它以1970-01-01 T 00:00 UTC為基準,每秒加 1 方式計算,如果是在基準點之前,就每秒 -1 方式計算。例如,我們把上述 Unix Time 放到http://www.unixtimestamp.com/進行轉換:

Timestamp Converter

就能還原成特定的時間點。因為數值的特性直覺、簡單、好處理,所以 Unix time 常被拿來做 Timestamp 使用。

升級舊專案中SQLLocalDb v11.0至v12.0

升級舊專案中SQLLocalDb v11.0至v12.0

Visual Studio SQL Server Express提示

舊專案裡保留著測試用的SqlLocalDb(*.mdf)檔案,在Visual Studio 2015開啟後會有一些提示,可以看到專案圖示明顯不同,也能看到提示訊息明確指出SqlLocalDb有版本上的差異。查了目前這台電腦,因為SSD空間有限,除了Visual Studio 2015之外,並無額外再安裝MS SQL Server (Express),查詢程式與功能確定Visual Studio 2015有安裝Microsoft SQL Server 2014 Express LocalDB。還要下載Microsoft SQL Server 2012 Express LocalDB?沒那麼笨吧!

程式與功能 - SQL Server 2014 Express LocalDB

試著點擊LocalDb(*.mdf),這次得到的線索很明確了。

Visual Studio LocalDb 連線錯誤

遷移專案MSBuild-Integrated Package Restore至Automatic Packages Restore

遷移MSBuild-Integrated Package Restore專案至Automatic Packages Restore

nuget參考錯

在前面VSO簽出packages少了dll怎麼辦?因為是採用NuGet Packages簽入VSTS版控(VSO改名為VSTS)碰到一些問題,還好平常都是看黑大的文章長大的,沒有花費許多時間就順利把問題排除。不過,最近在整理一個舊專案時,在不同電腦簽出之後實在很容易碰到NuGet套件的問題,有了第一次成功的經驗當然信心滿滿,立馬進行舊專案升級使用Automatic Packages Restore。結果就是上圖…

刪除NuGet組態

按照前文,我們進行了.nuget目錄的刪除,這樣會把下面三個MSBuild-Integrated Package Restore所使用的組態與.exe給刪除:

  • NuGet.Config
  • NuGet.exe
  • NuGet.targets

並把專案目錄下的packages目錄刪除。重新簽入(簽入後建議把本機版本刪除)與簽出(確認最新無.nuget與packages目錄版本)。其實到這裡都沒有錯,重新建置能看到 NuGet 有進行套件還原的動作,packages目錄也順利出現在專案目錄之下,建置就會如上圖一樣,一堆黃色三角型,一堆找不到參考元件的錯誤。

如何於MVC/Web API路由中傳送Base64編碼

如何於MVC/Web API路由中傳送Base64編碼

base64
from technet.microsoft.com

之前提到過如何使用路由傳遞含"+"符號到ASP.NET Web API 2有二種方式,一是使用QueryString,一是修改allowDoubleEscaping,不過allowDoubleEscaping的修改會降低系統安全性,是個不得以的選項。重覆的問題又活生生出現在面前,只是這一次必須把這個含+符號的值放在路由中。怎麼辦?有無更好的方式解決這個問題呢?

+號+號你為什麼會出現

首先,第一次處理如何使用路由傳遞含"+"符號到ASP.NET Web API 2問題時,那是一段對稱加密的程式,因為是中間接手處理,沒有細看實作細節,我們以DESCryptoServiceProvider (DES 的實作)為例來說明:

 private string Encryption(string plainText)                
 {                                                                      
     if (plainText == null || plainText.Length <= 0)                    
         throw new ArgumentNullException("cipherText");

     byte[] b = Encoding.UTF8.GetBytes(plainText);                      
     DESCryptoServiceProvider des = new DESCryptoServiceProvider();     
     ICryptoTransform ict = des.CreateEncryptor(des.Key, des.IV);               
     byte[] desData = ict.TransformFinalBlock(b, 0, b.Length);
                                                                        
     return Convert.ToBase64String(desData);                            
 }                                                                       
 
DES加密程式

看出問題點了嗎?

我們先看看這個的字串如果使用在路由上會產生什麼問題,以/{controller}/{action}/{id}路由為例:/home/index/EZ7+/+wvla4=,怎麼+號(加號)都還沒處理就馬上出事了?

看的出來了嗎?

有在寫MVC或Web API的人,第二個問題很直覺就能看出來了,多了一個「/」符號,此時就算設置allowDoubleEscaping讓路由能正常處理+號,id透過ModelBinding後還是不正常的。

回到問題一,看出問題了嗎?

設定VS2015 Update1中Go To Implementation快速鍵

設定VS2015 Update1中Go To Implementation加上快速鍵

如果各位在程式裡、專案間開始使用介面(Interface)來溝通,那是一個好的開始,習慣介面導向設計(interface-oriented design)或介面隔離原則(Interface Segmentation Principle, ISP)最大好處是斷開相依,一個介面能有多個實作,並且在需要時透過多型來執行對應的實作。但也有壞處是,壞處不是指介面本身,而是在 IDE 開發工具除錯介面不是那麼方便,Visual Studio 2013/2015多半會安裝第三方套件 Implementator(2013) 或 Go To Implementation 來解決這方面的需求。

設置Go To Implementation快速鍵