Где объединить данные базы данных с данными файловой системы в .NET

#c# #.net #architecture #structure

#c# #.net #архитектура #структура

Вопрос:

Я создаю приложение .NET Core Web API, в котором люди могут находить планы застройки домов.

Приложение имеет таблицу базы данных, которая содержит такую информацию, как адрес, почтовый индекс, город и идентификатор.

PDF-файлы хранятся в файловой системе и группируются в папках с тем же идентификатором, что и в базе данных.

Это мой текущий код контроллера:

 [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);
}
  

Однако этот код кажется неправильным; В контроллере слишком много логики, которую я хочу поместить куда-нибудь еще. Хотя я не знаю, куда это поместить.

Кто-нибудь может подсказать мне, куда поместить эту логику? Я также открыт для других советов.

Ответ №1:

Вам нужно создать слой вашего приложения, где каждый слой имеет определенное назначение. Наиболее базовым разделением является UI-Logic-Data, но существуют и другие, более продвинутые архитектуры, например https://morphological.wordpress.com/2011/08/29/5-layer-architecture (мой пост в блоге).

Думайте о контроллере API как о пользовательском интерфейсе — он должен отвечать только за обработку запроса API и предоставление ответа; «тяжелая работа» по объединению данных, которые входят в ответ, будет выполняться в другом месте.

Например, базовая трехуровневая модель может выглядеть следующим образом:

  1. Уровень API — отвечает за обработку внешних запросов API.

  2. Логический уровень — отвечает за принятие решений, таких как организация различных вызовов, обеспечение соблюдения бизнес-правил и так далее.

  3. Уровень данных / сервиса — отвечает за выборку данных, например, из базы данных, файловой системы или внешнего API.