ASP.NET 伺服器控制項的核心特性是**「執行在伺服器、輸出至客戶端」**。使用者在瀏覽器操作 (輸入文字、點擊按鈕) 觸發 **PostBack**，表單資料傳回伺服器，經過事件處理後，重新渲染完整頁面回傳。本文透過一個互動式實驗室練習，讓讀者親身體驗這個來回往返的生命週期。
實驗環境與步驟
- 啟動 Visual Studio .NET 實驗室環境
- 開啟「Server Controls」範例專案
- 頁面包含：姓名輸入框、類別下拉選單、Lookup 按鈕、結果顯示區
操作流程演示
| 步驟 | 使用者動作 | 伺服器端處理 | 瀏覽器呈現 |
|---|
| 1 | 輸入姓名 "Daniel" | — | 文字顯示於輸入框 |
| 2 | 選擇類別 "Employees" | — | 下拉選單更新 |
| 3 | 點擊 **Lookup** 按鈕 | - 表單 PostBack (HTTP POST)
- `Page_Load` 執行
- `btnLookup_Click` 事件處理
- 查詢資料庫/商業邏輯
- 更新結果控制項屬性
- `Page_Render` 輸出新 HTML
| 頁面重繪，顯示查詢結果 |
關鍵技術點解析
1. runat="server" 的魔力
<asp:TextBox ID="txtName" runat="server" />
<asp:Button ID="btnLookup" Text="Lookup" OnClick="btnLookup_Click" runat="server" />
- 標記 `runat="server"` 讓 ASP.NET 在伺服器端建立對應控制項實例
- 自動參與 ViewState 狀態管理 (啟用時)
- 支援伺服器端事件繫結 (`OnClick="btnLookup_Click"`)
2. PostBack 往返細節
瀏覽器 伺服器
│ │
├─ POST /Default.aspx ─────────►│ (含 __VIEWSTATE、表單欄位)
│ ├─ Page 初始化
│ ├─ LoadViewState
│ ├─ Page_Load
│ ├─ btnLookup_Click
│ ├─ Page_PreRender
│ ├─ SaveViewState
│ ├─ Render → HTML
│◄─ 200 OK (新 HTML) ──────────┤
│ │
└─ 重繪頁面 │
3. 事件驅動 vs 傳統 ASP 線性執行
| 傳統 ASP | ASP.NET WebForms |
|---|
| 單一 .asp 檔從頭執行到尾 | 頁面類別實例化，特定事件觸發特定方法 |
| 狀態靠隱藏欄位/Session 手工維護 | ViewState 自動維護控制項狀態 |
| HTML 與程式碼混雜 | 標記與 CodeBehind 分離 |
| 難以單元測試 | 事件處理器可獨立測試 |
實驗室觀察重點
- 點擊 Lookup 後，**網址列不變** (同一 URL)，但頁面內容更新 → **PostBack 本質**
- 輸入框的值 **自動保留** → ViewState 作用
- 若關閉 ViewState (`EnableViewState="false"`)，PostBack 後輸入框會清空
- 伺服器端程式碼 (C#/VB.NET) 決定頁面行為，瀏覽器只負責顯示
現代化對比：為什麼現在較少用 PostBack？
- 體驗：整頁重繞 → 閃爍、捲動位置重置、回應慢
- 頻寬：每次傳送完整 HTML + ViewState (常超過 100KB)
- 架構：前後端耦合，難以單元測試、SEO 不友善
- 替代：AJAX (UpdatePanel)、Web API + 前端框架、Blazor (WebAssembly)
延伸練習建議
- 在 `Page_Load` 加入 `if (!IsPostBack) { ... }` 觀察差異
- 使用 `Trace="true"` 觀察控制項樹、ViewState 大小、事件順序
- 嘗試 `UpdatePanel` 包裹 Lookup 區塊，體驗部分頁面更新
- 重寫為 `$.ajax` 呼叫 `.asmx`/`Web API`，比較程式碼結構差異
這個簡單的實驗室練習，浓縮了 ASP.NET WebForms 最核心的**伺服器控制項、PostBack、事件驅動、ViewState**四大支柱。親手操作、觀察網路流量、閱讀 Trace 輸出，是建立扎實 WebForms 直覺的最快捷徑。
