dotnet-design-pattern-review

.NET/C# 設計模式審查

審查 ${selection} 中的 C#/.NET 程式碼，針對設計模式實作提出改進建議。請勿修改程式碼，僅提供審查意見。

必要設計模式

• 命令模式 (Command Pattern)：泛型基底類別 (CommandHandler<TOptions>)、ICommandHandler<TOptions> 介面、CommandHandlerOptions 繼承、靜態 SetupCommand(IHost host) 方法
• 工廠模式 (Factory Pattern)：複雜物件建立的服務提供者整合
• 依賴注入 (Dependency Injection)：主要建構子語法、ArgumentNullException 空值檢查、介面抽象化、適當的服務生命週期
• 儲存庫模式 (Repository Pattern)：非同步資料存取介面、連線的提供者抽象化
• 提供者模式 (Provider Pattern)：外部服務抽象化（資料庫、AI）、明確的合約、設定處理
• 資源模式 (Resource Pattern)：ResourceManager 用於在地化訊息、獨立的 .resx 檔案（LogMessages、ErrorMessages）

審查檢查清單

• 設計模式：識別使用的模式。命令處理器、工廠、提供者和儲存庫模式是否正確實作？是否缺少有幫助的模式？
• 架構：是否遵循命名空間慣例 ({Core|Console|App|Service}.{Feature})？Core/Console 專案之間是否有適當的分離？是否模組化且可讀？
• .NET 最佳做法：主要建構子、async/await 搭配 Task 回傳、ResourceManager 使用、結構化記錄、強型別設定？
• GoF 模式：命令、工廠、樣板方法、策略模式是否正確實作？
• SOLID 原則：是否有違反單一職責、開放封閉、里氏替換、介面隔離、依賴反轉原則？
• 效能：適當的 async/await、資源釋放、ConfigureAwait(false)、平行處理機會？
• 可維護性：清楚的關注點分離、一致的錯誤處理、適當的設定使用？
• 可測試性：透過介面抽象化的相依性、可 mock 的元件、非同步可測試性、AAA 模式相容性？
• 安全性：輸入驗證、安全的憑證處理、參數化查詢、安全的例外處理？
• 文件：公開 API 的 XML 文件、參數/回傳值說明、資源檔案組織？
• 程式碼清晰度：反映領域概念的有意義命名、透過模式表達明確意圖、自我說明的結構？
• 整潔程式碼：一致的風格、適當的方法/類別大小、最小複雜度、消除重複？

改進重點領域

• 命令處理器：基底類別中的驗證、一致的錯誤處理、適當的資源管理
• 工廠：相依性設定、服務提供者整合、釋放模式
• 提供者：連線管理、非同步模式、例外處理與記錄
• 設定：資料註解、驗證屬性、安全處理敏感值
• AI/ML 整合：Semantic Kernel 模式、結構化輸出處理、模型設定

提供具體、可操作的改進建議，並與專案架構和 .NET 最佳做法保持一致。