Вопрос чистого кода: EF Core параметризует, какие свойства включать

Question

Этот вопрос касается чистого кода и лучших практик. Мы используем . NET Core 3.1 для разработки веб-приложения. Допустим, у нас есть PostsController, который принимает запросы, PostService, который возвращает некоторые данные из базы данных, и Post модель базы данных с некоторыми свойствами.

public class PostsController : Controller
{
    private readonly IPostsService _postsService;

    public PostsController(IPostsService postsService)
    {
        _postsService = postsService;
    }

    public IActionResult Get(int id)
    {
        Post post = _postsService.Get(id);
        return View(post);
    }
}

public class PostsService : IPostsService
{
    private readonly MyDbContext _dbContext;

    public PostsService(MyDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public Post Get(int id)
    {
        return _dbContext.Post
            .Include(x => x.FirstPropery)
            .FirstOrDefault(x => x.Id == id);
    }
}

Все хорошо, верно? Но давайте скажем, что есть другой контроллер (или другая служба, на самом деле не имеет значения), которая также вызывает _postsService.Get(id), но ему не нужен Post с просто FirstProperty. Это также нуждается в его SecondPropery. Поэтому подходящей сервисной функцией для него будет:

public Post Get(int id)
{
    return _dbContext.Post
        .Include(x => x.FirstPropery)
        .Include(x => x.SecondPropery)
        .FirstOrDefault(x => x.Id == id);
}

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

Что нам делать в этом случае?

1. Создать n различных методов обслуживания, каждый из которых возвращает сообщение с различными включенными свойствами? Ужасно.
2. Создать общий метод обслуживания, который включает ALL свойства? Ужасно, медленно, многие свойства не нужны.
3. ...?

Есть ли способ параметризации, какие Include s вам нужны? Я не хочу жестко кодировать любые строковые свойства, так как это может привести ко многим ошибкам. Мне нужно чистое решение, которое произвело бы ошибку времени компиляции, если мы изменим имя некоторого свойства в Post модели.

Answer 1

Представьте, что может быть n контроллеров, которым все нужны Post по своему Id, но каждому нужны свои собственные включенные свойства.

Вот почему ваши контроллеры должны иметь доступ к IQueryable<Post> , Это тип, который позволяет контроллеру указывать запрос. Альтернатива, которую вы предлагаете, - это очень ограниченный, самодельный API-интерфейс, позволяющий контроллеру контролировать запрос.