面對多樣化的行動裝置 (手機、PDA、智慧型手機早期裝置),ASP.NET 開發者需解決「同一內容、不同呈現」的難題。本文深度比較三大主流策略:**多導航路徑**、**XML/XSLT 轉換**、**Microsoft Mobile Internet Toolkit (MMIT)**,分析架構優劣、資源消耗、維護成本,協助技術選型。
策略一:多導航路徑 (Multiple Navigation Paths)
做法
- 針對每種裝置類型建立獨立頁面/目錄:`/wap/`、`/pda/`、`/html/`
- 透過 `Request.Browser` 偵測裝置,導向對應版本
- 類似早期處理瀏覽器相容性 (Frame/Table/CSS 支援度不同)
優缺點
| 優點 | 缺點 |
| 實作直觀,無需新技術 | 頁面數量隨裝置類型**指數增長** |
| 每版面可深度客製化 | 維護惡夢:修改功能需同步 N 套頁面 |
邏輯重複度高,違反 DRY |
| 新裝置上市需新增整套路徑 |
策略二:XML + XSLT 轉換
架構
資料來源 (DB/XML) → XML 資料流 → XSLT 樣式表 (每裝置一套) → 裝置專屬 HTML/WML/cHTML
優缺點
| 優點 | 缺點 |
| 內容與呈現**完全分離** | **效能較差**:每請求動態轉換,CPU/記憶體壓力大 |
| 新增裝置只需新增 XSLT | XSLT 撰寫門檻高,除錯困難 |
| 資料層僅輸出 XML,可複用 | 需深厚 XML/XPath/XSLT 專業知識 |
| 符合標準,跨平台可移植 | 早期行動裝置對 XSLT 輸出支援度不一 |
策略三:Microsoft Mobile Internet Toolkit (MMIT)
核心創新:裝置獨立控制項 + 裝置適配器
開發者使用統一控制項 (Mobile Controls)
↓
ASP.NET 執行階段偵測裝置能力 (Request.Browser)
↓
對應裝置適配器 將控制項渲染為該裝置標記語言
↓
WML (WAP手機) / cHTML (i-mode) / HTML (PDA/智慧型手機)
關鍵優勢
| 特性 | 說明 |
| 單一頁面、單一控制項樹 | 程式碼複用率極高,維護成本低 |
| 內建狀態管理 | ViewState/Session 自動運作,無需自行實作 |
| Visual Studio 整合 | 工具箱拖曳、設計器預覽、專案範本 |
| 擴充性 | 自訂控制項繼承 `MobileControl`,新裝置只需新增適配器 |
| 表單互動 | 自動處理回發、驗證、按鈕點擊跨裝置一致性 |
三策略綜合比較
| 維度 | 多路徑 | XML/XSLT | MMIT |
| 開發速度 | 快 (初期) | 中 (需 XSLT 專長) | 快 (工具支援好) |
| 維護成本 | 極高 | 中 (集中在 XSLT) | 低 |
| 伺服器效能 | 最好 (靜態頁面) | 差 (動態轉換) | 中 (適配器渲染開銷) |
| 擴充新裝置 | 重寫整套 | 新增 XSLT | 新增適配器 |
| 狀態管理 | 自行實作 | 自行實作 | 內建支援 |
| 適用專案 | 極少數裝置、極度客製化 | 內容導向、跨平台標準化 | 企業級行動應用、需快速交付 |
技術演進與現代啟示
- MMIT 後併入 **ASP.NET 2.0 `System.Web.UI.MobileControls`** (現已標記過時)
- 現代行動開發:**響應式網頁設計 (RWD)** + **CSS Media Queries** 取代伺服器端適配
- **漸進式 Web 應用 (PWA)**、WebAssembly (Blazor) 統一桌面/行動體驗
- 原生 App:Xamarin/.NET MAUI、React Native、Flutter
- 核心思想不變:**關注點分離** (內容/邏輯 vs 呈現)、**單一來源真理** (Single Source of Truth)
選型建議決策樹
專案需支援多少裝置類型?
├─ 1-2 種,且極度客製化 → 多路徑 (或直接 RWD)
├─ 內容為主、需標準化輸出 → XML/XSLT (或現代 Headless CMS + API)
└─ 企業級應用、表單互動複雜、需快速迭代 → MMIT (歷史) / 現代:RWD + Blazor / PWA
雖然 MMIT 已成為歷史名詞,但其**「裝置獨立控制項 + 適配器模式」**的架構智慧,深刻影響了後續 ASP.NET Core 的 Tag Helper、ViewComponent、以及現代跨平台 UI 框架的設計哲學。理解這段演進歷程,有助於在技術選型時穿透表象,抓住本質。