Why and in which cases should I use each?
I believe that using DbContext directly, you end up getting caught / stuck technology, being a disadvantage if you need to change in the future.
Another disadvantage of using DbContext directly in the service is that your service involves business rules, already DbContext is related to a technology. So if you change the technology, you'll need to tweak the code where your business rules are, that's not cool.
In the second example why not use a generic repository? is not it more practical?
Repository isolates domain (business-related) objects from access code details and mapping these objects to the database. That is, it adds a layer of separation between the data access and domain layers.
In the case of the project you are developing, you would have to create another project in your solution to implement this design pattern . I believe it is more practical and recommendable to use this pattern.
Is it bad practice to instantiate another service and make use of it?
No , each service has its responsibility and in many cases one service may need another service.
Example: In a scenario where a Customer takes a draw on your account, we assume that the Customer has a service called CustomerService.
public class ClienteServico
{
//...
public void RealizarSaque()
{
//Nesse ponto pode ser que o cliente não tenha saldo para saque
//e você precisa de um serviço de um objeto ContaCorrenteServiço
//por exemplo para retornar/verificar o saldo antes do saque
}
//...
}
Following this reasoning, I would recommend that you also work with dependency injection and control inversion of repositories / services, according to Thiago Custodio's response (but not only in the controllers, also in their services that will depend on queries to repositories, etc. .).
