在何处将数据库数据与 .NET 中的文件系统数据合并

Question

我正在创建一个.NET Core Web API应用程序，人们可以在其中找到房屋的建筑计划。

该应用程序有一个数据库表，其中包含地址，邮政编码，城市和ID等信息。

PDF 存储在文件系统上，并分组在与数据库中具有相同 ID 的文件夹中。

这是我当前的控制器代码：

[HttpGet]
public async Task<ActionResult<List<BuildingplanDto>>> Get(
    [FromQuery] string street,
    [FromQuery] string city,
    [FromQuery] string housenumber)
{
    //Retrieve building plan info from database
    List<Buildingplan> buildingplans = await _BuildingplanService.FindAsync(street, city, housenumber);
    List<BuildingplanDto> buildingplanDtos = new List<BuildingplanDto>();
    BuildingplanDto buildingplanDto;
    foreach (Buildingplan buildingplan in buildingplans)
    {
        //Map database entity to Dto
        buildingplanDto = _mapper.Map<Buildingplan, BuildingplanDto>(buildingplan);
        //Add folders from the filesystem to the Dto
        buildingplanDto.Folders = _documentService.GetFolders(buildingplan.DossierId);
        buildingplanDtos.Add(buildingplanDto);
    }
    return Ok(buildingplanDtos);
}

但是，此代码感觉不正确;控制器中有太多的逻辑，我想放在其他地方。我不知道把它放在哪里。

谁能给我一个方向，把这个逻辑放在哪里？我也愿意接受其他提示。

Answer 1

您需要对应用程序进行分层，其中每个层都有特定的用途。 最基本的分层是UI-Logic-Data，但还有其他更高级的架构 - 例如 https://morphological.wordpress.com/2011/08/29/5-layer-architecture/(我的博客文章(。

将 API 控制器视为 UI - 它应该只负责处理 API 请求并提供响应;将进入响应的数据放在一起的"繁重工作"将在其他地方完成。

例如，基本的 3 层模型可能如下所示：

API

1. 层 - 负责处理外部 API 请求。

2. 逻辑层 - 负责做出决策，例如编排各种调用、执行业务规则等。

3. 数据/服务层 - 负责获取数据，例如从数据库、文件系统或外部 API 获取数据。