為何需要依賴注入？ 分層架構核心原則：**上層不依賴下層具體實現，而依賴抽象介面**。若 BLL 直接 new SqlDAL()，更換資料庫即須修改 BLL 程

系列脈絡與本篇目標 承接前文架構搭建，本系列規劃三種 DAL 實作，本篇為第一種：Access 資料庫 + 動態生成 SQL 指令。適合中小型專案、桌面應用或輕

背景與痛點：初版實作的三大缺失 在前一篇〈基於 .NET 平台的分層架構實戰（七）——資料存取層第一種實現：Access+SQL〉發布後，社群反饋熱烈（特別感謝

背景與步驟 上篇討論 SQL 構建 DAL (Access)。本篇針對 SQL Server，配合存儲過程實現。關於 SQL 與存儲過程效率差異，資料顯示一般情

ORM 簡介與框架選擇 對象關係映射 (ORM) 連接面向對象開發與關係數據庫。.NET 平台有 NHibernate、NBear 等。本文選用 NBear (

業務邏輯層 (BLL) 的核心職責 BLL 承載系統最核心部分，客戶最關注。實現通常需技術專家與領域專家合作。本 Demo 因業務簡單可能不明顯。本篇 BLL

表示層的重要性與評價指標 表示層是系統「門面」。系統設計再優秀、代碼再漂亮、擴展性再高，用戶最終接觸的是表示層。優劣兩指標：美觀 (外觀設計漂亮) 與 易用 (

引言：企業開發的兩大痛點 微軟提供廣泛產品技術支撐企業部署與應用構建。企業開發者面臨兩大困境： 空記錄問題 (從何處開始)： 應用複雜，需多個空專案作起點。

WPF 內建 Panel 的不足 WPF 內建 Panel 功能基礎，常見場景支持不佳： 項目間有 Margin，但首/尾項需特殊處理不需要 Margin。

痛點與發現 以往寫 GetElementUnderMouse 需座標轉換，遇元素有 Transform 更麻煩。今日發現 Mouse 類有 DirectlyOv

問題背景 啟用審批的 SharePoint 列表，透過物件模型修改已批准項目並 Update 會導致項目回到「待定」狀態。物件模型有 SystemUpdate

前言 上篇介紹了如何使用 SharePoint 伺服器上的 BCS 物件模型連接中繼資料存儲，獲取外部內容類型 (ECT) 及其方法並執行。本文示範如何執行帶有

問題場景 專案中發現同一數據契約在客戶端屬於兩個不同命名空間，導致兩服務交互時類型不匹配，互操作性差，需額外拆裝轉換。以下重現場景： 實體類 (命名空間: G

DBA 的噩夢：EF 預設生成 CRUD 命令 看到 EF 實際生成的命令，DBA 首先反應往往是：「什麼？我必須給表訪問權？」因為 EF 核心功能正是生成

測試場景與方法 本文對比 Entity Framework 中三種查詢單個實體的方式：LINQ to Entities、Entity SQL、EntityKey

背景與動機 近期專案中某政務系統需可配置的 IP 訪問控制。基於先前使用 IHttpHandlerFactory 驗證用戶的經驗，本次採用 HttpModule

什麼是 MEF？ Managed Extensibility Framework (MEF) 讓開發者能在 .NET 應用程式中提供掛鉤，供使用者與第三方擴充。

緒論：被討論至厭卻又不得不面對的議題 關於記憶體模型，這是個被「說爛」了的話題。五六年前初接觸 .NET 時，各路大牛便開始探討。當時懷著崇敬之心閱讀那些文字與

前言：從 CLR 2.0 到 4.0 的演進 自 CLR 2.0 起，執行緒集區經歷了多次重大重構。隨著多核架構的普及，以及將既有應用程式並行化或編寫新並行代碼

隨著多核心處理器普及，平行程式設計成為必備技能。Visual Studio 2010 引入非同步代理程式庫（Asynchronous Agents Librar