You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

317 lines
11 KiB

# AuroraDesk 架构分析与优化方案
## 📋 问题分析
### 1. AuroraDesk.Application 项目完全没有作用
**当前状态**:
- ✅ 创建了 `AuroraDesk.Application` 项目
- ✅ 创建了 `DTOs/NavigationConfig.cs`
-**没有任何 UseCase 或 ApplicationService**
-**没有任何地方引用这个项目**
-**NavigationConfig 从未被使用**
**问题根源**:
- 项目是按整洁架构创建的,但没有实际的业务用例需要处理
- 所有业务逻辑都在 ViewModels 和 Infrastructure Services 中
- Application 层变成了一个"空壳"
### 2. 文件位置不合理
**当前文件分布**:
```
AuroraDesk.Core/
└── Interfaces/
├── INavigationService.cs ✅ 接口定义
├── IPageViewModelFactory.cs ✅ 接口定义
└── ...
AuroraDesk.Application/
└── DTOs/
└── NavigationConfig.cs ❌ 未使用
AuroraDesk.Infrastructure/
└── Services/
├── NavigationService.cs ✅ 接口实现
├── TabManagementService.cs ✅ 接口实现
└── ...
AuroraDesk.Presentation/
└── Services/
└── PageViewModelFactory.cs ⚠️ 应该在 Infrastructure?
└── LanguageManager.cs ⚠️ 位置合理?
└── ViewModels/
└── Pages/
├── DashboardPageViewModel.cs
└── ...
```
**主要问题**:
1. `PageViewModelFactory` 放在 Presentation 层
- 它在实现 `IPageViewModelFactory` 接口
- 接口在 Core 层定义
- 按照整洁架构,实现应该在 Infrastructure 层
2. `LanguageManager` 的位置
- 它是 UI 资源管理
- 在 Presentation 层是合理的
3. `NavigationConfig` DTO
- 没有被使用
- 如果要用,应该用来配置导航菜单
- 但实际配置都在 `NavigationService` 中硬编码
## 🎯 解决方案
### 方案A:删除 AuroraDesk.Application 层(推荐)
**适用场景**:当前业务逻辑简单,没有复杂的业务用例
**优点**:
- ✅ 简化项目结构
- ✅ 减少不必要的层次
- ✅ 符合 YAGNI 原则(You Aren't Gonna Need It)
- ✅ 清晰的依赖关系
**修改内容**:
1. 删除 `AuroraDesk.Application` 项目
2.`NavigationConfig.cs` 移到 `Core/DTOs/` 或删除
3. 更新 `Presentation.csproj` 移除对 `Application` 的引用
4. 更新 `AuroraDesk.sln` 移除项目引用
**架构图**:
```
┌─────────────────────────────┐
│ AuroraDesk (主项目) │
│ - App.axaml.cs │
│ - 组合所有层 │
└─────────────────────────────┘
↓ 依赖
┌─────────────────────────────┐
│ Presentation │
│ - ViewModels │
│ - Views │
│ - Services/PageViewModel │
│ Factory (工厂) │
└─────────────────────────────┘
↓ 依赖 ↓ 依赖
┌─────────────────────────────┐ ┌──────────────────────────┐
│ Infrastructure │ │ Core │
│ - Services 实现 │←─│ - Entities │
│ - NavigationService │ │ - Interfaces │
│ - TabManagementService │ │ - DTOs │
└─────────────────────────────┘ └──────────────────────────┘
```
### 方案B:正确使用 Application 层(适合复杂业务)
**适用场景**:有复杂的业务逻辑需要处理
**实现内容**:
1. **创建 UseCase 类**
```csharp
// AuroraDesk.Application/UseCases/NavigationUseCase.cs
public class NavigationUseCase
{
private readonly INavigationService _navigationService;
public NavigationUseCase(INavigationService navigationService)
{
_navigationService = navigationService;
}
public ObservableCollection<NavigationItem> GetNavigationItems(IScreen screen)
{
// 业务逻辑:可能涉及权限检查、动态配置等
return _navigationService.GetNavigationItems(screen);
}
}
```
2. **创建 ApplicationServices**
- `NavigationApplicationService` - 导航业务逻辑
- `TabApplicationService` - 标签页业务逻辑
3. **使用 DTOs**
-`NavigationConfig` 配置导航菜单
- 从配置文件或数据库加载
**优点**:
- ✅ 符合整洁架构标准
- ✅ 适合复杂业务场景
- ✅ 更好的关注点分离
**缺点**:
- ❌ 当前项目不需要
- ❌ 增加复杂性
- ❌ 违反 YAGNI 原则
### 方案C:调整文件位置
**不删除 Application 层,但调整文件位置**:
1. **将 `PageViewModelFactory` 移到 Infrastructure**
- ✅ 因为它是接口实现
- ❌ 但它依赖 Presentation 的 ViewModel 类型
- **问题**:Infrastructure 不能依赖 Presentation
**此方案不可行!** 因为违反依赖倒置原则。
**正确的做法**:
- `PageViewModelFactory` 依赖 ViewModel 类型
- ViewModel 类型在 Presentation 层
- 所以工厂必须在能够访问 Presentation 的地方
- **主项目(AuroraDesk)是唯一选择**
### 方案D:将工厂移到主项目
**架构调整**:
```
AuroraDesk (主项目)
├── App.axaml.cs
├── Services/
│ └── PageViewModelFactory.cs ← 放在这里
└── Extensions/
└── ServiceCollectionExtensions.cs
Presentation
└── ViewModels/
└── Pages/
Infrastructure
└── Services/
└── NavigationService.cs ← 使用 PageViewModelFactory
```
**优点**:
- ✅ 主项目可以访问所有层
- ✅ 符合依赖注入原则
- ✅ Infrastructure 不依赖 Presentation
**缺点**:
- ⚠️ 主项目需要引用 Presentation
- ⚠️ 主项目变得更复杂
**实际检查**:
```bash
# 当前主项目引用
AuroraDesk.csproj:
- 引用 Presentation ✅
- 引用 Infrastructure ✅
- 不引用 Core ❌
- 不引用 Application ❌
```
## 🎨 推荐方案
### 推荐:方案A + 方案D 的组合
**即**:
1. **删除 `AuroraDesk.Application` 项目**
- 因为它完全没有作用
- 业务逻辑都在 Infrastructure 和 Presentation
2. **保持 `PageViewModelFactory` 在 Presentation**
- 因为它是 UI 层的工厂
- 依赖 ViewModel 类型
3. **主项目引用 `Core` 和 `Infrastructure`**
- 不直接引用
- 通过 `Presentation` 间接引用
4. **更新主项目引用**
```xml
<ProjectReference Include="..\AuroraDesk.Presentation\AuroraDesk.Presentation.csproj" />
<ProjectReference Include="..\AuroraDesk.Infrastructure\AuroraDesk.Infrastructure.csproj" />
<ProjectReference Include="..\AuroraDesk.Core\AuroraDesk.Core.csproj" />
```
## 📊 最终架构
```
┌─────────────────────────────────────────┐
│ AuroraDesk (主项目) │
│ - App.axaml.cs │
│ - 依赖注入配置 │
│ - 组合所有层 │
└─────────────────────────────────────────┘
↓ 依赖
┌─────────────────────────────────────────┐
│ AuroraDesk.Presentation (表示层) │
│ - ViewModels/Pages/ │
│ - Views/ │
│ - Services/ │
│ ├── PageViewModelFactory.cs │
│ └── LanguageManager.cs │
│ - Converters/ │
└─────────────────────────────────────────┘
↓ 依赖 ↓ 依赖
┌─────────────────────────┐ ┌──────────────────────────┐
│ Infrastructure │ │ Core │
│ - Services/ │←─│ - Entities/ │
│ ├── NavigationService│ │ ├── NavigationItem │
│ ├── TabManagement │ │ └── TabItem │
│ └── ... │ │ - Interfaces/ │
│ - Configuration/ │ │ ├── INavigationService│
│ - Extensions/ │ │ └── ... │
└─────────────────────────┘ └──────────────────────────┘
```
## 🔍 为什么 Application 层没有作用?
**根本原因**:
- 当前项目是典型的 **CRUD 应用**
- 没有复杂的业务逻辑
- 所有操作都是:
1. 导航到页面
2. 展示数据
3. 标签页管理
- 这些都在 Infrastructure 和 Presentation 层完成
**什么时候需要 Application 层**:
- 复杂的业务规则(如计算逻辑、验证逻辑)
- 跨多个实体的操作
- 工作流管理
- 领域事件处理
- 复杂的权限检查
**当前项目**:
- 导航:Infrastructure.NavigationService ✅
- 标签页:Infrastructure.TabManagementService ✅
- 状态管理:Infrastructure.NavigationStateService ✅
- UI 管理:Presentation 层 ✅
**不需要额外的 Application 层!**
## ✅ 行动建议
**推荐执行**:
1. ✅ 删除 `AuroraDesk.Application` 项目
2. ✅ 将 `NavigationConfig.cs` 移到 `Core/DTOs/` 或删除
3. ✅ 更新 `Presentation.csproj` 移除 Application 引用
4. ✅ 更新 `AuroraDesk.sln` 移除项目
5. ✅ 保持 `PageViewModelFactory` 在 Presentation(位置正确)
6. ✅ 检查并优化文件组织
**可选优化**:
- 📁 考虑在 `Core` 创建 `DTOs` 文件夹(如果需要)
- 📁 考虑在 `Infrastructure` 创建 `Factories` 文件夹(如果需要)
## 📝 总结
**当前问题**:
1.`AuroraDesk.Application` 项目完全无用
2. ✅ 文件位置总体合理(PageViewModelFactory 在 Presentation 是正确的)
3. ⚠️ `NavigationConfig` DTO 未使用,应该删除
**解决方案**:
- 删除无用项目
- 保持现有文件位置
- 优化项目引用
**架构原则**:
- ✅ YAGNI(You Aren't Gonna Need It)
- ✅ KISS(Keep It Simple, Stupid)
- ✅ 整洁架构(适合项目规模)