mirror of
https://github.com/jackqqq123/luban_ui_internal.git
synced 2025-11-15 13:48:24 +08:00
119 lines
3.8 KiB
Markdown
119 lines
3.8 KiB
Markdown
# 项目架构设计文档
|
||
|
||
## 一、总体说明
|
||
|
||
本项目采用 **Avalonia** 作为跨平台桌面UI框架，目标是让非程序员也能轻松使用Luban管理配置表。项目结构高度模块化，底层能力与业务服务解耦，便于维护和扩展。
|
||
|
||
---
|
||
|
||
## 二、架构分层
|
||
|
||
### 1. Core（基础能力库，单独程序集）
|
||
|
||
|
||
命名空间：**LubanHub.Core**
|
||
- 封装所有原生能力：下载、文件管理、进程调用、解压缩等
|
||
- 只暴露通用接口，供各业务服务调用
|
||
- 例如：`ICoreFileService`、`ICoreDownloadService`、`ICoreProcessService`
|
||
|
||
### 2. 各业务服务（每个服务一个程序集）
|
||
|
||
|
||
- **Luban集成服务**
|
||
- 命名空间：**LubanHub.LubanService**
|
||
- 负责调用Luban命令行、管理Luban相关配置、版本检测等
|
||
- 依赖Core的进程调用、文件管理能力
|
||
|
||
- **知识库应用服务**
|
||
- 命名空间：**LubanHub.KnowledgeService**
|
||
- 管理本地知识库、历史会话
|
||
- 封装AI API调用（如OpenAI、本地模型等）
|
||
- 依赖Core的文件管理、网络能力
|
||
|
||
- **配置表管理服务**
|
||
- 命名空间：**LubanHub.TableService**
|
||
- 管理配置表结构、配置表设计器逻辑
|
||
- 支持table/enum/bean等结构
|
||
- 依赖Core的文件管理
|
||
|
||
- **模板工程创建服务**
|
||
- 命名空间：**LubanHub.TemplateService**
|
||
- 负责扫描luban_example、按模板生成新工程
|
||
- 支持变量替换、目录操作
|
||
- 依赖Core的文件管理、解压缩等
|
||
|
||
### 3. UI层（Avalonia MVVM）
|
||
|
||
|
||
命名空间：**LubanHub.App**
|
||
- 只负责界面展示与交互，所有业务逻辑通过服务层调用
|
||
- 通过依赖注入获取服务实例
|
||
|
||
---
|
||
|
||
## 三、依赖关系示意
|
||
|
||
```
|
||
UI层
|
||
│
|
||
├─ Luban集成服务
|
||
│ │
|
||
│ └─ Core
|
||
├─ 知识库应用服务
|
||
│ │
|
||
│ └─ Core
|
||
├─ 配置表管理服务
|
||
│ │
|
||
│ └─ Core
|
||
└─ 模板工程创建服务
|
||
│
|
||
└─ Core
|
||
```
|
||
|
||
---
|
||
|
||
## 四、主要功能模块
|
||
|
||
- **问答**：本地知识库、历史会话、AI对话
|
||
- **项目管理**：分组、创建、打开、配置、发布
|
||
- **配置表设计器**：结构化编辑、字段类型、处理器、分组、备注、导出标记
|
||
- **模板工程生成**：基于luban_example按模板生成新工程
|
||
- **设置页**：外观、Luban文档、外部编辑器、shell路径、语言等
|
||
|
||
---
|
||
|
||
## 五、架构原则
|
||
|
||
### 1. 服务注册原则
|
||
- **优先使用装饰器注册服务**：所有服务类使用 `[RegistService]` 特性标记，实现自动发现和注册
|
||
- **避免手工注册**：减少在 DI 容器中手动添加服务，降低耦合度和维护成本
|
||
- **支持生命周期配置**：通过装饰器参数指定服务生命周期（Singleton/Scoped/Transient）
|
||
|
||
### 2. 依赖方向原则
|
||
- **LubanHub.Core 不能引用任何其他服务**：作为基础能力库，Core 必须保持纯净，只能依赖系统库和第三方基础库
|
||
- **其他服务可以引用 Core**：业务服务层可以依赖 Core 提供的基础能力
|
||
- **业务服务间避免相互引用**：各业务服务应保持独立，通过事件或接口解耦
|
||
|
||
### 3. 接口设计原则
|
||
- **Core 服务必须定义接口**：如 `ICoreFileService`、`ICoreDownloadService` 等
|
||
- **业务服务建议定义接口**：便于测试和扩展
|
||
- **接口与实现分离**：接口放在 Interfaces 目录，实现放在 Services 目录
|
||
|
||
### 4. 装饰器使用示例
|
||
```csharp
|
||
[RegistService(ServiceLifetime.Singleton, typeof(ICoreFileService))]
|
||
public class CoreFileService : ICoreFileService
|
||
{
|
||
// 服务实现
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 六、开发建议
|
||
|
||
- Core层实现时注意跨平台兼容
|
||
- 业务服务只依赖Core，不直接操作系统API
|
||
- UI层只做展示和交互，所有逻辑下沉到服务
|
||
- 使用装饰器模式实现服务的自动发现和注册
|