服務契約 ServiceContract 標註於介面，而非類別：分離契約與實作。 契約名稱以 I 開頭：IMyContract。 避免屬性式操作：如 GetN

操作與呼叫 單向調用 ≠ 非同步調用：單向僅表示不等待回應，不代表非同步執行。 單向調用 ≠ 並發調用：不具備並發語意。 單向操作仍可能拋出例外：用戶端需處理

交易 切勿手動管理交易：交由 WCF 基礎設施處理。 TransactionFlow 屬性標註於契約介面，而非服務類別。 服務建構函數內不執行交易工作。 服務

佇列服務 用戶端調用前驗證佇列可用性：含死信佇列，使用 QueuedServiceHelper.VerifyQueues()。 裝載時自動驗證：Service

應用場景：IP 封鎖名單快取 系統需在使用者註冊或登入時檢查 IP 是否被封鎖。封鎖名單存放於資料表 IPBlocked，變動頻率低，適合快取；但一旦資料表異動

異常處理的困境 對於 .NET 開發人員而言，異常處理既熟悉又棘手。熟悉是因為語法僅止於 try/catch；棘手則在於：try/catch 該放在哪？何時記錄

概述 測試驅動開發（Test Driven Development，TDD）是一種先編寫單元測試，再編寫實際代碼以通過測試的開發方法。單元測試可視為系統行為的微

作者以實戰案例開啟系列，記錄從失敗的 SOA 專案 (AIM) 吸取教訓，到主導新專案 (PPM) 設計通用框架的完整思考路徑。 AIM 專案：教科書級的反面

前言：架構設計始於腦中，不止鍵盤前 Richard 採用「筆 + 紙」推演：腦中先跑通流程、細節、異常，再落鍵盤。參考 Microsoft Best Pract

前言：草圖背後的隱憂與歷史包袱 承接上篇草圖，Richard 發現三大核心問題： DAL 綁死 LINQ 實體：技術選型無彈性，專案 B 想換 EF 無從下手

前言：架構師的三大核心能力 Richard 認為設計框架需具備：**整體把控力、抽象能力、分析能力**。本篇從「以不變應萬變」的 DAL 核心操作出發，推導出通

前言：從手工編碼到模型驅動的跨越 系列前四篇奠定了 DAL、Repository、Query Object 等基礎設施。讀者反饋 (感謝 金色海洋、Virus)

前言：跨越「資料鴻溝」的銀彈？ Silverlight 4 帶來印表、提權、WebCam 等豐富能力，但業務開發核心痛點仍是：**如何將伺服器端業務邏輯與資料，

前言：單請求 10 萬筆訂單的效能困境 呼叫 Web Service 一次性取回 100,000 筆訂單，易導致： 請求逾時 (Timeout) 記憶體暴漲

前言：模型優先、POCO、OData 的三重奏 VS 2010 帶來 EF 4.0 (Model-First、FK、Lazy Loading、T4、POCO)

前言：為什麼需要自訂模板？ 團隊開發中，統一代碼風格、自動帶入作者/時間/版權/公司等資訊，能大幅降低 Code Review 成本、避免版權糾紛。Visual

前言：BackgroundWorker 的侷限與突破 .NET 2.0 引入的 BackgroundWorker 簡化了單任務異步，但面對「同時下載多個檔案、並

前言：兩種風格的碰撞 ADO.NET：規矩、嚴謹、專注資料存取，猶如《美麗心靈》裡的納什教授。 dynamic：不按牌理出牌、無所不能、與 Lambda 是冤家

前言：分久必合，合久必分 企業級 WinForm 系統隨業務增長，模組化是控制複雜度的關鍵。本文實戰分享三大高頻模組——資料字典、參數配置、權限管理——的獨立設

前言：XPS 與 Silverlight 的邂逅 XPS (XML Paper Specification) 是微軟推出的固定版面文檔格式，與 Adobe PD