Context in services and repositories

Question

In the company we work, we use Asp.net mvc divided into 2 projects:

• web - (groundwork)
• service - (business rules)

In several places I have noticed other programmers using the direct context (that extends Dbcontext) in the services and I have seen also using a context where contains all the registered repositories:

Context example (Dbcontext)

var contexto = new DatabaseContext();
contexto.Produtos....
contexto.Pessoas....

Example repositories

contexto.ProdutosRepositorio...
contexto.PessoasRepositorio...

Now comes the doubts:

• Why and in which cases use each?
• In the second example why not use a generic repository? is no longer practical?

Taking advantage...

• It is bad practice for one service to instantiate another and make use of that?

Answer 1

Why and in which cases use each?

I believe using Dbcontext directly, you end up being tied/tied to the technology, being a disadvantage if you need to change in the future.

Another disadvantage to use Dbcontext directly in the service is that its service involves business rules, already Dbcontext is related to a technology. So, if you change the technology, you will need to touch the code where are your business rules, this is not cool.

In the second example why not use a generic repository? is no longer practical?

Repository isolates domain objects (business-related) from access code details and mapping those objects with the database. That is, it adds a layer of separation between the layers of data access and domain access.

In the case of the project that you are developing, you would have to create another project in your solution to implement this Pattern design. I believe it is more practical and recommended to use this standard.

It is bad practice for one service to instantiate another and make use of that?

Not, each service has its own responsibility and in many cases one service may need another service.

Example: In a scenario where a Customer withdraws into their account, let’s assume that the Customer has a service called Clienteservice.

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 also recommend you to work with dependency injection and inversion of control of repositories/services, according to the answer of Thiago Custodio (but not only in controllers, but also in their services that will depend on repository queries, etc.).

Answer 2

In my opinion the second way is the correct one!

Forget DI doesn’t pay!

As for the generic repository is exactly what the name says... you can use a generic or a repository for each model, adapt as the process and evolution of your project.

If you choose to use the generic repository in the future when creating a specified repository you need to refactor.

Answer 3

Ideal would be to inject the repositories / services into the controllers. This way, you can automate tests without actually hitting the bank.

http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection