- 這系統一定是一個團體才會需要用的，如果你只有兩三個人，用講的比較快... 通常是部門、辦公室、或是規模不大，可以一起訂便當的團體會需要使用。這需要基本的每日訂單管理，還有簡單的會員管理功能。
- 既然是 Multi-Tenancy Application, 那麼用 SaaS (Service as a Service) 的方式營運也是很理所當然的。所有客戶通用的內容，就可以由營運單位來負責整理及規劃。
- 除了切割很多獨立的 "分割區" 各自運作之外，Hosting 的一方其實也有很多商機，像是合作的餐聽或是便當店，這些資料就可以共用。甚至是可以主動匯入，讓客戶訂購起來更方便。若這樣能為便當店帶來生意，Hosting 的一方抽點庸金也是很合理的 XD
- 後台 BI 也是很有商機的一環。Service Hosting 的一方，就可以看看各種統計報表，看跟那家餐廳合作的機會較大，另外也可以設計客戶 share 他們自己開發的便當店資訊，給其它客戶使用。若越多客戶採用，可以給些系統租金的回饋等等….
越想越多，再想下去這個 POC 用的 prototype 就寫不完了，需求給各位讀者再去延伸，我這邊作 POC 就把需求收殮一下...。偷學一下 SCRUM 的 story 撰寫技巧，以下是我這次 POC 要實作的 stories:
好，看來一個設計良好的 DataContext, 可以省掉不少工夫。大部份的 coding logic, 都是在客戶的專區內運作的。我把整套系統稱作 "Hub”, 而每個客戶專區內的資料，就通稱為 "HubData”, 如會員資料，或是訂單等等。而其它非 HubData, 就是整個系統通用的資料。因此，我希望 Hub 用的 Data Context 能有這些功能:
- 取得 HubDataContext 時，就已經能確定目前是在那個 Client 的使用範圍。
- HubDataContext 能直接提供該 Client 才能用的 Data Collection, 我只要拿來再用 Linq 過濾即可，即使我沒控制好，也不會拿到別的 Client 專區內的 HubData。
- 全域 (共用) 的資料則不在此限。每個 Client 都能完整存取這些資料內容。
OK，噴了三篇的口水，終於看到第一段程式碼了 Q_Q，HubDataContext 的 interface 看起來要像這樣:
使用它的 Code 要像這樣 (這段我就寫在 unit test 內…):
花了一點時間，總算把實作都寫出來，成功通過單元測試了。套句 Luddy Lee 前輩常說的話，寫雲端的程式測試跟佈署都比以前麻煩，因此做好完整的規劃跟測試就變的更重要了，單元測試是少不了的，請各位切記。過去吃了很多苦頭，更加證明 Luddy Lee 前輩講的話一點都沒錯....
最終的 HubDataContext 實作如下... 其實也沒幾行:
OK，第一步通過了，接下來我們開始來規劃一下 Data Schema …. Azure Table Storage 已經沒有所謂的 "schema” 這回事了，它完全就像 EF5 裡面的 code first 一樣，你的 Data Entity class 定義好，就可以跑了... 這些細節就不在這篇裡多做說明，各位有興趣可以參考其它的資料。既然都是 Code First 開發模式了，我就直接用 class diagram 來描述這些資料 (Entity) 之間的關係:
