[Azure] Multi-Tenancy Application #3, (資料層)實作案例
摘要提示
- 設計目標: 在資料層以 DataContext 階段完成租戶資料隔離，讓開發者用一般方式就能開發多租戶應用。
- URL 虛擬化: 透過 MVC Routing 在網址邏輯上劃分租戶層級，提供每個租戶獨立的虛擬目錄。
- 資料/網站整合: Web 與 Data 架構緊密結合，開發者無需為租戶隔離撰寫額外樣板程式。
- 技術棧: 以 Windows Azure Storage + ASP.NET MVC4 為核心，示例系統為「訂便當系統」。
- SaaS 營運模式: 共享內容由平台營運方維護，支援跨租戶共用資料與營運拓展。
- 商機延伸: 餐廳資料共享、自動匯入、抽佣、BI 報表與客戶分享機制。
- Hub 架構: 全系統稱為 Hub；租戶專屬資料稱 HubData，共用資料另行管理。
- HubDataContext 要件: 啟用即綁定租戶、只暴露該租戶的資料集合、共用資料不受限。
- 測試驅動: 雲端開發測試與佈署更複雜，完整規劃與單元測試不可或缺。
- 資料模型: 以 Azure Table Storage 的 Code First 思維規劃 Entity 關係，不拘泥傳統 schema。
全文重點
本文延續前篇的設計討論，聚焦於在 Azure 上實作多租戶應用資料層的具體作法。作者的核心期望，是把租戶隔離的邏輯前移到 DataContext，使應用程式開發者能以熟悉的 Entity Framework 開發模式思考與操作，卻自動獲得租戶級別的資料隔離；同時在 Web 端以 ASP.NET MVC 的路由機制，將租戶維度前置於 URL 結構中，讓每個租戶具備獨立的虛擬目錄與操作範圍。這種設計使資料層與網站層緊密耦合而非相互脫節，降低跨層處理租戶邏輯的複雜度。
示例選擇「訂便當系統」，因其天然符合多租戶特性：通常由部門或團隊共同使用，需要每日訂單與會員管理；且作為 SaaS 運營時，營運方可維護通用內容，並藉由餐廳資料共享、自動匯入、交易抽佣等機制擴展商業價值。更進一步，營運方可利用後台 BI 做餐廳合作策略與跨客戶資料的可分享設計，打造網路效應與租金回饋模式。鑑於此題材可能無限延伸，本文聚焦於一組 POC 的實務故事與核心能力。
為此，作者定義了 Hub 與 HubData 的概念：整體系統稱 Hub；每個客戶租戶的專屬資料（如會員、訂單）稱 HubData；跨租戶的共用資料則另行管理。HubDataContext 作為關鍵組件，需滿足三項能力：建立時即綁定當前 Client（租戶）範圍；僅暴露該租戶可用的資料集合，避免跨租戶誤取；共用資料則不受租戶限制。這種 API 設計讓開發者用 Linq 常態地操作資料集合，卻天然具備安全的租戶隔離。
在工程實務上，作者強調雲端開發比傳統更仰賴嚴謹測試與部署流程，因此以單元測試驗證 HubDataContext 的關鍵行為，確保在多租戶資料隔離與共用資料存取上皆符合預期。通過測試後，作者給出精簡的 HubDataContext 實作，證明設計可行且落地成本不高。
最後，本文概述資料模型的規劃：Azure Table Storage 無需傳統關聯式 schema，採近似 EF Code First 的方式，直接以 Entity 類別定義資料結構與關係。作者以類別圖來描述實體關聯，並將 schema 設計的細節留待讀者延伸與參考其他資料。總結來說，本文提供了一條以資料層為核心、結合 MVC 路由的多租戶實作路徑，兼顧開發體驗、租戶隔離與營運擴展性。
段落重點
實作導向與開發期望
作者從設計轉入實作，設定目標是在 DataContext 層即完成租戶資料隔離，讓開發者用一般 EF/Linq 習慣進行查詢與儲存，不必在業務邏輯層重複寫租戶過濾。並在 Web 端以 MVC 路由擴充出 client 維度，使每個租戶擁有獨立的 URL 空間與邏輯範圍。這種前置式隔離策略減少跨層樣板碼，並統一資料與路由的租戶語意。
MVC 路由與租戶虛擬目錄
在網址層加入租戶識別（如 /{client}/{controller}/{action}），讓應用程式像虛擬化一樣，租戶可視為獨立分割區。如此能將租戶語境傳遞到控制器與資料層，使用戶操作天然落在其專區內，強化體驗的一致性與安全性，也為後續權限與快取策略鋪路。
選題與 SaaS 營運思維
「訂便當系統」適合做多租戶：滿足團體日常需求，具會員與訂單管理；在 SaaS 模式下，通用內容由平台統一維運，減低客戶負擔。藉此平台可整合餐廳資料、導流下單、抽佣，並促成資料網效。該題材既能驗證技術，也能對接實際商業模式。
商機延伸與 BI 報表
平台可與餐廳合作共享菜單與庫存資訊，甚至主動匯入，提升下單便捷；若能帶來營收，平台抽取服務費順理成章。後台可做跨租戶 BI：分析餐廳偏好、熱銷品項、時段趨勢；也可設計客戶分享自建餐廳資料的機制，帶動擴散並以採用度回饋租金，形成良性循環。
Hub 與 HubData 的資料域界定
系統稱 Hub，租戶專屬資料統稱 HubData（如會員、訂單）；共用資料獨立於 HubData。此分層使租戶私有與平台共用邏輯清晰。多數商業邏輯在租戶域內運作，平台域則提供共享資源與服務，兩者邊界明確，有助於權限、快取與儲存策略差異化。
HubDataContext 的設計需求與測試
HubDataContext 必須：1) 建立時即鎖定當前租戶；2) 只暴露該租戶可用的資料集合，讓 Linq 操作安全且直覺；3) 共用資料不受租戶限制。作者以單元測試驗證這些契約，確保查詢與儲存都不會越租戶邊界。強調雲端專案測試與部署的複雜性，完整測試為成功關鍵。
Azure Table Storage 與 Code First 模型
規劃資料模型時，採用 Azure Table Storage 的無 schema 特性，近似 EF 的 Code First：以實體類別直接定義資料形狀與關係，由類別圖表達關聯與邏輯鍵（如 Partition/Row Key 的設計）。這種做法降低前期 schema 成本、提升迭代速度，亦符合多租戶場景對分割與擴展的要求。作者將更細節留給讀者延伸研究。
資訊整理
知識架構圖
- 前置知識：
- Multi-Tenancy 與 SaaS 基本概念（租戶隔離、共享資源）
- Azure Storage（特別是 Table Storage）與其資料模型
- ASP.NET MVC（Routing、Controller/Action 基礎）與 LINQ
- Entity Framework/Code First 思維（概念比實作工具更重要）
- 單元測試與雲端部署測試流程
- 核心概念（及關係）：
- Hub 與 HubData：Hub 為整體系統，HubData 為每個租戶的專屬資料；兩者需清楚區分「租戶資料」與「全域共享資料」
- HubDataContext：在建立時就確定目前租戶範圍，對外僅提供該租戶可見的資料集合；全域資料不受此限制
- URL 分割（Routing 加一層 client）：在網址層決定租戶身分，與 HubDataContext 的租戶範圍相呼應
- Code First 與 Schema-less：以類別定義資料實體，對應 Azure Table Storage 無需預先 schema
- 測試先行：雲端情境下單元測試更重要，確保隔離邏輯與資料存取正確
- 技術依賴：
- MVC Routing 客製化 -> 解析 client/tenant -> 傳入或注入 HubDataContext
- HubDataContext -> 封裝 Azure Table Storage 操作 -> 只暴露租戶範圍內的資料集合 -> 由 LINQ 再行過濾
- Azure Table Storage -> 承載 HubData 與全域資料 -> 與 Code First 類別對映
- 單元測試 -> 驗證租戶隔離與共用資料行為 -> 支撐雲端部署品質
- 應用場景：
- 訂便當系統的多租戶化（部門/辦公室等團體使用）
- 平台端維護共用餐廳/便當店目錄，供所有租戶使用或匯入
- 平台端抽成、營運與合作夥伴管理
- 後台 BI 與跨租戶統計分析（支援商務決策與營運優化）
學習路徑建議
- 入門者路徑：
- 了解 Multi-Tenancy 與 SaaS 基本概念與常見隔離策略
- 建立簡單的 ASP.NET MVC 專案，熟悉 Routing 與 Controller/Action
- 了解 Azure Table Storage 基礎（帳號、Table、Entity、基本 CRUD）
- 練習以類別（Code First 思維）建模資料實體並以 LINQ 存取
- 進階者路徑：
- 客製 MVC Routing，於 URL 加入租戶識別（如 /{client}/{controller}/{action}）
- 設計與實作 HubDataContext：在建立時注入/解析租戶；暴露租戶限定的資料集合
- 規劃租戶資料與全域資料的界線、命名與資料夾層
- 為關鍵邏輯撰寫單元測試（租戶隔離、全域可見性、邏輯查詢）
- 實戰路徑：
- 以「訂便當系統」為專案：成員、訂單、餐廳目錄等模型設計與資料流
- 導入平台共享餐廳資料與租戶端匯入/客製流程
- 佈署至 Azure，配置儲存體、監控與診斷；迭代完善 BI/報表
- 審視安全性（認證/授權）、審計與租戶資料備份/回復策略
關鍵要點清單
- 租戶隔離策略（資料層）: 在 Data Context 層面強制租戶範圍，避免跨租戶資料外洩 (優先級: 高)
- Hub 與 HubData 分界: HubData 為租戶專屬，Hub 中亦含全域共享資料，需清晰界定 (優先級: 高)
- HubDataContext 設計: 建立時即綁定租戶，僅提供該租戶的資料集合 (優先級: 高)
- URL 層租戶辨識: 透過 MVC Routing 在網址加入 client 層，與資料層租戶範圍一致 (優先級: 高)
- 全域資料存取: 全域（共用）資料不受租戶範圍限制，需有明確存取界線 (優先級: 高)
- Azure Table Storage 概念: Schema-less、以實體類別對映、輕量高延展 (優先級: 中)
- Code First 思維: 以類別定義資料結構與關聯，快速迭代資料模型 (優先級: 中)
- LINQ 查詢與過濾: 在租戶範圍內再以 LINQ 做細部過濾查詢 (優先級: 中)
- MVC Routing 客製化: 實作多一層 client segment 的路由規則與綁定 (優先級: 中)
- 單元測試在雲端的重要性: 雲端部署與測試成本高，單元測試必不可少 (優先級: 高)
- 訂便當系統作為題材: 多租戶的典型案例，需求清晰易於切分 (優先級: 低)
- 平台共享資源與匯入: 共用餐廳資料由平台維護，租戶可匯入加速上線 (優先級: 中)
- 營運與商業模式: 合作餐廳、抽成、共享資料的回饋機制 (優先級: 低)
- 後台 BI 與報表: 跨租戶統計分析，支援營運與商務決策 (優先級: 中)
- 資安與授權考量: 租戶識別、權限控管、審計與資料保護 (優先級: 高)
