1. The general wisdom is that the dbcontext is already a repository and you should use Select statements to grab only the data you require from the database. So in your service you can do something like

    await context.Movies.Where(...)
    .Select(m => new { Property1,Propert2, ... })
    .AsAsyncEnumerable()
    .SelectAsync(m => new Dto(...))

this way you only pull the exact fields you need.

2. Just new up genre, add your movie to it and add it to the dbcontext and call save changes.

3. Again just do a where against the context.

4. It is and there's no need to add another layer that limits what you can do with it.

This argument for a repo layer was all the rage about 10 years ago. It is absolutely not required and as you've identified makes working with the dbcontext a pain.

For testing either mock the dbcontext or use the in memory db provider.

One thing to look at to formalize your queries is compiled queries. These give you strongly typed queries and removed the SQL generation step each time you run it.

I'm not too familiar with EF specifically, but I'll give you my general advice:

1. Column filtering can be done in either the repository or service layer.
2. Your transaction should be scoped to the service method. MovieService should call both repositories.
3. Prefer filtering in the repository
4. I don't know this one

It think you get it. Repositories are superfluous abstractions that are focused on mocking databases for unit testing. They are entirely unnecessary, unless you're being micromanaged over unit tests.

Additional question - I said at first that the "Service" should be doing the mandatory checks like uniqueness validation or whether the fields are filled in properly with good values, but is even that a good approach?

Instead of implementing this in every service that might create a new Movie (and it could be from different sources - import from file, different APIs, background worker, etc), wouldn't it make more sense to add these checks to the repository itself so they always gets called?

Alternatively, do we have to handle a constraint violation in every service or could we just have the repository return a result with failure if it happens?

In short, once I start thinking in this way I start to wonder why even have a separation between repository and service.

How I think about repositories:
These are simple wrappers around database calls that have few or no dependencies. If I'm adding dependencies here, then they'll either be a cache or a logger.

Make repositories as simple as possible, because texting them sucks. You make a repository because it makes unit testing your service easier.

How I think about services:
Services are just groups of related methods. In a simple CRUD API, I would typically do a service per controller and include all business logic at the service level.

How I think about controllers:
These should be treated like repositories and only contain logic for determining which response code to send.