Lemoo.UI：从一组控件到可扩展的 WPF 应用骨架¶
Lemoo.UI 最初是一个现代化 WPF 控件库，后来逐步扩展为包含主题、图标、示例应用、模块加载和通用基础设施的桌面应用骨架。
图标浏览器早期界面；当前图标数据已扩展至 1,403 项，并改为数据驱动加载。
控件库关注的不只是外观¶
项目覆盖按钮、输入、布局、导航、数据展示、通知、对话框和可视化等控件类别。每个自定义控件尽量遵循 WPF 的原生使用方式：
- 通过依赖属性支持绑定、样式和动画；
- 将默认外观放在资源字典中，避免业务代码直接控制视觉；
- 使用命令和 MVVM 组织交互；
- 为浅色、深色和扩展主题复用同一套语义资源键。
这样做的目标不是“画出一个更漂亮的 Button”，而是让控件在不同业务、主题和数据上下文中仍然可组合。
图标系统：数据与渲染解耦¶
图标系统从早期几百个硬编码条目扩展到 1,403 个图标。继续手工维护枚举、路径和浏览器列表会产生重复劳动，因此我将它改造成数据驱动流程：
flowchart LR
Source[图标源数据] --> Generator[IconGenerator]
Generator --> Metadata[名称 / 分类 / Path 数据]
Metadata --> Control[Icon 控件]
Metadata --> Browser[虚拟化图标浏览器]浏览器只创建视口附近的容器，并启用回收，搜索与分类在数据层完成。优化重点从“减少一个控件模板的耗时”转向“不要为不可见的上千项创建完整视觉树”。
主题系统：使用语义资源，而不是散落颜色¶
业务控件不直接绑定某个固定色值，而是引用背景、表面、边框、正文、弱文本和强调色等语义资源。切换主题时，ThemeManager 替换对应资源字典，现有控件通过动态资源自动刷新。
项目还包含 Aurora、Neon Cyberpunk、Sunset Tropics 等风格主题。它们不是复制一整套控件模板，而是尽量复用控件结构，通过资源层改变视觉语言。
从 UI 库延伸出的模块化架构¶
当前解决方案拆分为 Core Abstractions、Application、Domain、Infrastructure、Hosts、Modules 与 UI 多个层次，并包含 TaskManager 示例模块。代码中可以看到 CQRS、Pipeline Behavior、Repository / Unit of Work、模块发现、隔离加载、健康检查与消息总线等基础能力。
这些能力并不意味着每个桌面工具都必须使用完整架构。它们主要用于验证：当应用从组件 Demo 增长到包含多个业务模块时，UI 库如何与宿主、领域逻辑和基础设施保持边界。
质量保障与当前边界¶
仓库包含控件、应用和基础设施测试项目，源码中约有 225 个 [Fact] / [Theory] 测试标记。由于 WPF 测试受 Windows UI 线程、目标框架和本机 SDK 影响，我不会仅凭测试数量宣称全部环境通过；发布前仍需要在固定 Windows 构建环境执行完整测试与示例应用冒烟验证。
当前仍需继续完善的部分包括：
- 控件 API 与主题资源的稳定版本规范；
- 键盘操作、屏幕阅读器和高对比度等无障碍验证；
- NuGet 打包、兼容性矩阵和示例文档；
- 模块加载能力的最小化，避免通用框架过度设计。
Lemoo.UI 让我积累的不只是 XAML 经验，更重要的是大型资源系统、视觉树性能、组件 API 和桌面应用边界的设计实践。