清洁代码问题：EF Core 参数化要包含的属性

Question

This question is about clean code and best practices. We are using .NET Core 3.1 to develop a web application. Let's say we have PostsController which accepts requests, PostService which returns some data from the database and Post database model with some properties.

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

Everything fine, right? But let's say that there is another controller (or another service, doesn't really matter) which also calls _postsService.Get(id) but it doesn't need Post with just FirstProperty . It also needs its SecondPropery . So appropriate service function for it would be:

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

Imagine that there could be n controllers all needing Post by its Id , but each needing its own included properties.

What should we do in this case?

1. Create n different service methods, each of them returning post with different included properties? Ugly.
2. Create a general service method which includes ALL properties? Ugly, slow, many properties are not needed.
3. ... ?

Is there a way to parametrize which Include s you need? I don't want to hardcode any string properties since it can lead to many errors. I need a clean solution which would produce compile time error if we change a name of some property in Post model.

Answer 1

Imagine that there could be n controllers all needing Post by its Id, but each needing its own included properties.

This is why your controllers should have access to an IQueryable<Post> . That's the type that allows the controller to specify the query. The alternative you are suggesting is just a very limited, home-grown API to give the controller control over the query.