Лучшие практики для получения 1 объекта из базы данных с использованием многоуровневой архитектуры WebApi C #

Question

Так что я знаю, что мой вопрос кажется основополагающим, но я хочу знать кое-что, что меня долго беспокоило, мой бэкэнд сделан в соответствии с многоуровневой архитектурой (repo-services-controllers)

У меня есть вызов API, который должен вернуть json сотрудника после предоставления его идентификатора, поэтому URL-адрес выглядит как api.mywebsite.com/api/employees/1

и мой контроллер будет выглядеть так:

public async Task<EmployeeDto> GetEmployee([FromUri] int eId)
{
    return GetService<IEmployeeService>().GetEmployeeById(eId);
}

мой вопрос: какие проверки я должен делать, когда получу этот объект? Должен ли я проверить, удален ли сотрудник (удаленное программное обеспечение)? Я, очевидно, должен сделать проверку, если он возвращает ноль (не нашел сотрудника с таким идентификатором)

Но если я хочу проверить, удалена ли сущность, я должен сделать это на уровне хранилища или на уровне службы? слой репо:

public Task<Employee> GetSingle(int id)
{
    return GetDatabase().Employees.Where(x => x.EmployeeId== id && !x.Deleted).SingleOrDefaultAsync();
}

или на уровне обслуживания:

var emp= await GetTenantRepository<IEmployeeRepository>().GetSingle(eId);
if (emp==null)
{
    throw ...
}
if (emp.Deleted)
{
    throw ...
}

Я слишком обдумываю это, и не имеет значения, положу ли я это здесь или там?

Answer 1

Это все о стиле кода, философии архитектуры и выбранном дизайне :) Ответ на ваш вопрос о том, «где поставить проверку»: это зависит от ответственности ваших уровней. Все примеры кода приведены только для справки и не должны рассматриваться как простое решение

1) DAL (репозиторий) - это мост от приложения к хранилищу. Он должен включать в себя все, что связано с взаимодействием с БД и деталями реализации БД. Таким образом, в случае отсутствия сущности можно вернуть значение null из интерфейса репозитория.

2) BL (служба) - объединяет необработанные данные, извлеченные из хранилища, и применяет к ним некоторые бизнес-правила / действия. В случае простой службы CRUD она становится очень похожей на репозиторий и может обрабатывать некоторые исключения из БД, выполнять преобразования данных (отображать объект DAL в BL) и т. Д. И снова нулевой результат, возвращаемый из уровня BL, указывает на отсутствующую сущность. Например. основываясь на вашем коде, вы можете инкапсулировать некоторую несогласованность БД и рассматривать несколько записей как пропущенное значение. Пример службы BL:

public async Task<EmployeeDto> GetEmployee(int eId)
{
    try
    {
        return GetService<IEmployeeService>().GetEmployeeById(eId);
    }
    catch (InvalidOperationException) //If it's suitable
    {
        return null;
    }
}

3) Уровень API (контроллеры) - это интерфейс RESTFUL. Он объединяет результаты из службы (служб) и представляет его как ресурсы, а также возвращает коды состояния и представление ресурсов. В случае отсутствия объекта лучшим способом будет вернуть статус 404 (HttStatusResult) из вашего RESTFUL API.

public async Task<IHttpActionResult> GetEmployee([FromUri] int eId)
{
    var res = GetService<IEmployeeService>().GetEmployeeById(eId);

    return res == null ? (IHttpActionResult)NotFound() : Ok(res);
}

Итак, вы можете проверить отсутствующий результат на ЛЮБОМ слое, но сделайте это правильно. Ваш репозиторий никогда не должен управлять поведением API (я имею в виду, что не следует разрабатывать код для ресурсов на DAL. Например, объект ресурса не должен иметь точно такой же реквизит, как объект DAL), BL никогда не должен влиять на DAL и наоборот.

P.S. это выходит за рамки вопроса, но взгляните на IoC и DI. Ваша текущая реализация DI, на мой взгляд, не самая лучшая.