通道：WCF 通訊的核心構件 通道負責傳輸、WS-* 協議、安全、交易處理。高組合性：可多種方式組合實現所需功能。可擴展：內部 API 允許自訂通道。絕大多數應

ICommunicationObject：統一狀態機契約 所有通道與工廠實作 ICommunicationObject，定義： 六種狀態：Created、

通道形狀：對應訊息交換模式 通道形狀對應第 3 章訊息交換模式（MEP）。.NET 介面天然適合區分形狀。對應表： MEP發送者形狀接收者形狀

IChannel：通道層查詢的入口 所有通道與通道工廠必須實作 IChannel（繼承 ICommunicationObject）。核心方法 GetProper

通道的三大功能面向 通道可實作任意訊息功能並嵌入 WCF 執行階段。概念上分為三類： 1. 傳輸通道 與網路、檔案系統、記憶體或外部系統（SQL Server

自訂通道設計原則：委派模式 本章建立 DelegatorChannel：在主控台列印追蹤訊息，示範通道生命週期與方法呼叫順序。核心設計——委派模式：通道執行特定

概述：通道管理器的雙重身分 使用者代碼不直接建立通道，由專門工廠類型完成。接收端稱為「通道偵聽器」，發送端稱為「通道工廠」，統稱「通道管理器」。雖非通道，但屬通

接收端的核心：通道偵聽器 通道偵聽器模仿 Berkeley Socket API：綁定 URI、被動偵聽連入訊息、連線建立後透過 AcceptChannel 回

發送端的核心：通道工廠 通道工廠位於發送端，負責建立通道。與通道偵聽器相似，但無需被動等待訊息，而是主動透過 CreateChannel 建立連線通道。每種傳輸

前言：愛恨交織的 Lock-Free 無鎖程式設計（Lock-Free）以高併發效能著稱，核心仰賴 CAS（Compare-And-Swap）原子操作。但在輕度

從 WinForms 到 WPF：版面配置的思維轉變 習慣 Windows Forms 開發的工程師，初接觸 WPF 時常在版面配置上碰壁。WinForms 中

前言：為什麼我們需要依賴注入？ 在現代軟體開發中，IoC 容器、控制反轉、依賴注入等術語早已司空見慣。Spring.NET、Castle Windsor、Uni

背景：UI 虛擬化 ≠ 數據虛擬化 類型機制解決問題 UI 虛擬化僅為可視區域建立視覺容器 (Container)，滾動時回收/重建視覺樹節點過多導致渲

前言：並行思考應在編碼前 傳統開發：選演算法 → 選語言 → 編碼 → 最後想並行。**並行必須是第一優先級**：任務內在並行性決定演算法選擇、資料結構設計、架

可伸縮性與加速比 加速比 = 串行執行時間 / 並行執行時間。2x 加速 = 並行耗時為串行一半。理想：雙核 2x、四核 4x。現實：多數應用進入多核時代**效

線程是什麼？ 現代作業系統採用 **搶占式多任務調度**。單核 CPU 透過極短時間片 (Windows ~20ms) 快速切換執行緒，欺騙人眼產生「同時運行」

場景：手動組裝 vs 容器自動組裝 傳統手動組裝 var dependency = new DependencyObject { Value = Depend

架構工具雙引擎：正向設計與逆向工程 VS 2010 架構工具支援： 正向：需求 → 架構 → 實體 (圖表驅動生成代碼) 逆向工程：現有代碼 → 依賴分析 →

痛點：官方安裝器極慢、強制聯網、卸載困難 官方 dotnetfx35setup.exe (引導程式) 體積小但**必須聯網下載本體**，下載速度極慢 (作者千兆

晶片簡介與硬體環境 WG7310 (TI WL1271) 整合 Wi-Fi (802.11 b/g/n)、Bluetooth 2.0/2.1+EDR、FM 收音