Actually, in a Web API application using Entity Core, it seems very common to inject the application context to the controllers, so the controllers use directly the dbContext to do its work.
Something like this:
[HttpGet]
public async Task<ActionResult<List<ActorDTO>>> GetAsync()
{
return await _contextConsultas.Actores.ToListAsync();
}
But I have some disavantages with this solution.
One is that what happen if I want to use a new version of entity core. Sometimes there are some breaking updates that modify the behavior of entity core. Perhaps how it is work an include or any other functionality. In this case, the controller has to know the implementation and the behaviour of entity core, and I should to modify all the endpoints in all the controllers.
If the controller would use a repository, and interface that is implemented by class, the controller doesn’t need to know the implementation, so if in the future I want to use another version that implements the interface, I can use it and the controller is not needed to be modify.
The code would be something like that:
[HttpGet]
public async Task<ActionResult<List<ActorDTO>>> GetAsync()
{
return await _applicationContex.GetAllActorsAsync();
}
Later, in the main project, if I am using dependency injection, I only need to chage the implementation that I want to use.
But seeing many examples in which the controller uses the dbContext directly, I am wondering if nowdays it is still as useful as I think to wrap the dbContext in a repository.
Thanks.
3
I think there are two reasons
-
Entity Framework. EF was intended to be used this way. It makes it “easy” to spin up the old style MVC razor webpages and apis. It does all your DB stuff for you and the controller builds the view so you have a simple three layer application, “out of the box”.
-
Microservice Architecture/Backend For Frontend. If you have a small API but implement a service layer, models, a data layer, entities and DTOs then you have a LOT of code which is really only needed for larger more complex projects. In your small project its just duplicated structs and wrapped empty layers. There is a strong argument to just drop it all and do one liner controller methods.
I am wondering if nowdays it is still as useful as I think to wrap the
dbContext in a repository.
EF and the repository pattern don’t mix well. Wrapping your context in a repository does separate your layers, but arguably you are better off not using EF, or try to bind directly to your Business Models with fluent setup rather than having separate Entities with attributes.
Also, I notice you have DTOs in your example. But if your models are anemic structs you can just return them from the controller directly, with no DTO required.
Compare
[HttpGet]
public async Task<ActionResult<List<ActorDTO>>> GetAsync()
{
return await _applicationContex.GetAllActorsAsync().ToDTOs();
}
AppContext
{
GetAllActorsAsync() { return _contextConsultas.GetAllActorsAsync() }
}
ActorDTO
{
...
}
Actor
{
...
}
ActorEntity
{
...
}
With
[HttpGet]
public async Task<IEnumerable<Actor>> GetAllActors()
{
return await _contextConsultas.GetAllActorsAsync();
}
Actor
{
...
}
6