dotnet-design-pattern-review

.NET/C# 设计模式审查

审查 ${selection} 中的 C#/.NET 代码，针对设计模式实现提出改进建议。不要对代码进行任何修改，仅提供审查意见。

必需的设计模式

• 命令模式：通用基类（CommandHandler<TOptions>）、ICommandHandler<TOptions> 接口、CommandHandlerOptions 继承、静态 SetupCommand(IHost host) 方法
• 工厂模式：复杂对象创建与服务提供者集成
• 依赖注入：主构造函数语法、ArgumentNullException 空检查、接口抽象、正确的服务生命周期
• 仓储模式：异步数据访问接口，为连接提供抽象
• 提供者模式：外部服务抽象（数据库、AI）、清晰的契约、配置处理
• 资源模式：用于本地化消息的 ResourceManager，独立的 .resx 文件（LogMessages、ErrorMessages）

审查清单

• 设计模式：识别使用的模式。命令处理器、工厂、提供者和仓储模式是否正确实现？是否缺少有益的模式？
• 架构：是否遵循命名空间约定（{Core|Console|App|Service}.{Feature}）？Core/Console 项目之间是否适当分离？是否模块化且可读？
• .NET 最佳实践：是否使用主构造函数、async/await 与 Task 返回、ResourceManager 用法、结构化日志、强类型配置？
• GoF 模式：命令、工厂、模板方法、策略模式是否正确实现？
• SOLID 原则：是否存在单一职责、开闭、里氏替换、接口隔离、依赖反转的违反？
• 性能：是否恰当使用 async/await、资源释放、ConfigureAwait(false)、并行处理机会？
• 可维护性：关注点分离是否清晰、错误处理是否一致、配置使用是否恰当？
• 可测试性：依赖是否通过接口抽象、组件是否可模拟、异步可测试性、AAA 模式兼容性？
• 安全性：输入验证、安全凭据处理、参数化查询、安全的异常处理？
• 文档：公共 API 的 XML 文档、参数/返回值描述、资源文件组织？
• 代码清晰度：有意义的名称反映领域概念、通过模式明确意图、结构自解释？
• 整洁代码：风格一致、方法/类大小适当、复杂度最小、消除重复？

改进重点领域

• 命令处理器：基类中的验证、一致的错误处理、适当的资源管理
• 工厂：依赖配置、服务提供者集成、释放模式
• 提供者：连接管理、异步模式、异常处理和日志记录
• 配置：数据注解、验证属性、安全处理敏感值
• AI/ML 集成：Semantic Kernel 模式、结构化输出处理、模型配置

提供具体、可操作的改进建议，与项目架构和 .NET 最佳实践保持一致。