I understand the basic principle but I have trouble determining what is the hard line separating responsibilities of a Repository or a Service. I’m mostly thinking in terms of c# .NET in the following example but I think the design pattern is kinda universal.
Let’s say I have tables “Movie” and “Genre”. A movie might have multiple genres associated with it. I have a MovieController with the usual CRUD operations. The controller talks to a MovieService and calls the CreateMovie method for example.
The MovieService should do the basic business checks like verifying that the movie doesn’t already exist in the database before creating, if all the mandatory fields are properly filled in and create it with the given Genres associated to it. The Repository should provide access to the database to the service.
It all sounds simple so far, but I am not sure about the following:
-
which layer should be responsible for column filtering? if my Dto return object only returns 3 out of 10 Movie fields, should the mapping into the return Dto be done on the repository or service layer?
-
if I need to create a new Genre entity while creating a new movie, and I want it to all happen in a single transaction, how do I do that if I have to go through MovieRepository and GenreRepository instead of doing it in the MovieService in which i don’t have direct access to the dbcontext (and therefore can’t make a transaction)?
-
let’s say I want to filter entries specifically to the currently logged in user (every user makes his own movie and genre lists) - should I filter by user ID in the MovieService or should I implement this condition in the repository itself?
-
is the EF DbContext a repository already and maybe i shouldn’t make wrappers around it in the first place?
Any help is appreciated. I know I can get it working one way or another but I’d like to improve my understanding of modern coding practices and use these patterns properly and efficiently rather than feeling like I’m just creating arbitrary abstraction layers for no purpose.
Alternatively if you can point me to a good open source projects that’s easy to read and has examples of a complex app with these layers that are well organized, I can take a look at it too.
- 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.
-
Just new up genre, add your movie to it and add it to the dbcontext and call save changes.
-
Again just do a where against the context.
-
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.
