.NET 分布式架構實戰 (二) 草稿設計：從紙筆推演到分層解耦雛形

前言：架構設計始於腦中，不止鍵盤前

Richard 採用「筆 + 紙」推演：腦中先跑通流程、細節、異常，再落鍵盤。參考 Microsoft Best Practice 組織方式，避免過度設計，在權衡 (時間/資源/資金) 中演進。

一、首版草圖：分層雛形

• Presentation → Business Logic → Data Access → Database
• 服務層 (WCF) 疊加在 BLL 之上。
• 核心意圖：分層解耦、單一職責。

二、既有專案 DAL 深度剖析

問題 1：技術鎖定

DAL 直接引用 LINQ 實體 → 換 EF 需改動全站。架構需**預留技術切換介面** (Provider 模式)。

問題 2：缺乏基礎設施

• 異常處理、日誌追蹤、緩存、事務、安全驗證 —— 維護期價值巨大 (定位 Bug)、運行期價值巨大 (效能/安全)。
• 權衡：緩存策略 (什麼/哪裡/加密/過期/刷新) 需周全設計。

問題 3：資料源擴充性

未來可能對接外部服務/檔案/XML。架構需**預留資料源介面** (Service Agent 模式)。

解耦策略：Interface + Provider

BLL 僅依賴 IDataAccess，具體實現由 SqlProvider/LinqProvider/ServiceAgent 提供。

三、二版草圖：引入 Provider 與橫切關注點

• 資料源分類：Database / Text / XML / **Service Agent** (遠端服務特殊性單列)。
• 橫切關注點 (Log/Exception/Cache/Transaction/Security) 滲透各層。
• DAL 同時扮演 **Service Provider** (可被其他系統呼叫) —— 雙向橋接。

四、異常與策略前置思考

策略選擇：原生拋出 / 包裝異常 / 內部消化並友好提示 —— 視業務 SLA 決定。

五、服務化 DAL 的隱患 (留待下篇)

二版草圖將 DAL 發布為服務，但「DAL 作為服務被其他 DAL 呼叫」會形成遞迴依賴、事務邊界模糊。下篇深入破解。

結語

草圖迭代 = 思維迭代。從「分層」到「Provider + 橫切關注點 + 異常策略」，每一筆都源於對真實痛點的回應。出處：https://www.cnblogs.com/yanyangtian

1. 上一篇文章： .NET 分布式架構實戰 (三) 資料訪問層深度思考：從查詢爆炸到 Query Object 突破
2. 下一篇文章： .NET 分散式架構開發實戰（一）：專案背景與架構演進啟示

關於.NET

RapidWebDev 開源框架：基於 XML 配置的動態 UI 介紹

承接前文專案實戰，本文系統介紹 RapidWebDev 框架

三層架構完整解析：從餐廳比喻到代碼實戰，含優缺點深度對比

三層架構完整解析：從餐廳比喻到代碼實戰 核心概念：三層職責

WPF 4 DataGrid 進階樣式完全指南：ColumnHeader、RowHeader、Row、Cell 深度自定義

DataGrid 是 WPF 數據展示的核心控件，其視覺樹層

C# 字串本質深度剖析：驻留池、不可變性與 new 關鍵字的記憶體行為差異

C# 字串本質深度剖析：驻留池、不可變性與 new 關鍵字的