痛點：重複的檔案處理樣板代碼 為確保檔案處理健壯性，常寫大量 try-catch-finally 確保關閉檔案流。真正業務邏輯可能僅幾行，卻被大量樣板代碼包圍，

什麼是 Prism？ 企業級開發規模龐大，需拆分模組由不同團隊並行開發測試，最後整合。Prism (Composite Application Guidance

Composite Application 基本組成 CAL (Composite Application Library) 提供基礎組件與服務，典型架構包含：

前置準備 下載 CAL (Composite Application Library) DLL Visual Studio 2008+ 建立 Shell

Bootstrapper 角色 Prism 應用不使用傳統 StartupUri，改由 Bootstrapper.Run() 啟動，掌控完整啟動流程：載入模組、

為何需要 DI 容器 模組間鬆耦合仍需合作，DI 容器扮演橋梁：創建組件時自動注入依賴，避免直接引用。優點： 組件無需自行定位與管理依賴生命週期 替換實現不影

服務定位器模式 當類別依賴服務時，直接引用會造成耦合、生命週期管理分散、編譯期需具體實現。Service Locator 集中創建與管理服務，優點： 隔離具體

模組化設計原則 模組化將大型系統拆分為功能單一、自包含的子系統，提升獨立開發、測試與重用性。核心原則包括： 模組對外不透明，透過介面初始化 不直接引用其他模組

前言：為何 Prism 不直接使用 C# Event 或 WPF RoutedEvent？ 在 Prism 架構中，事件系統並未直接採用 C# 原生的 even

前言：WPF 內建命令的優勢與隱憂 Command 模式幾乎無所不在——複製、貼上、復原等操作皆是典型應用。它將「請求者」與「執行邏輯」解耦，並天然支援排隊、復

為什麼還要寫 Console App？ 這年頭習慣用 Console Application 的開發者似乎不多了，不管大小工具都愛拉一個巨大的 Form 出來。

系列緣起與整理說明 這系列文章早已在網路上廣泛流傳，我也曾在先前的部落格提供原文連結。鑑於博客園擁有更龐大的開發者社群，加上許多讀者強烈希望能在此平台重發，我決

雖然技術層面 DataTable 與 EntityObject 不可直接比較，但這隱喻著一場靜悄悄的革命正在發生——即便是微軟，也無法置身事外。軟體設計思想亟需

在進入具體實例之前，我們有必要回顧並深入理解分層架構。「層」是一種架構模式，也是軟體從業者最廣泛、最靈活運用的模式之一。雖然許多開發者知道「三層架構」即表現層、

案例：簡易銷售系統 實體：客戶、單據（銷售訂單/退貨單）、產品、產品類型。單據含多行。客戶可擁多張信用卡。EF Entity Data Model Design

EF 支援從存儲過程生成實體方法：為何說不？ 存儲過程屬技術架構（資料庫），實體方法屬領域模型（業務行為）。兩者混淆是典型反模式。 專家觀點佐證 「架構師指

聚合：表達完整領域概念的對象叢集 聚合將實體與值對象組合，共同表達一個完整業務概念。如「車」包含四個「輪子」，輪子離開車無意義，「車」為聚合根。 案例模型中的

生命週期兩大角色：工廠與倉儲 工廠：從無到有創建對象（充滿 new），負責建構完整聚合。倉儲：持久化、重建、刪除。 EF 自動生成的工廠方法 每個實體擁有靜態

生命週期狀態圖 對象由工廠創建 → 活動狀態參與業務 → 倉儲持久化/重建 → 記憶體中析構消亡 / 倉儲中撤銷刪除。 倉儲：領域層與基礎設施層的銜接器

為何需要倉儲？ 直接使用 EF ObjectContext + LINQ to Entities 雖簡單，但導致： 領域模型緊耦合 EF 技術架構。 查詢邏輯