.NET

23 ago, 2019

Estruturando Arquitetura API .Net Core 2.2

100 visualizações
Publicidade

Introdução

No artigo de hoje vamos estruturar uma web API .Net Core 2.2, separando em API, Domain, Repository e Services, utilizando o conceito de interfaces e clean code.

Mão na Massa

Vamos criar um novo projeto web no Visual Studio

Selecione API e utilize o Core 2.2

Após a criação, vamos ter essa estrutura no projeto:

O objetivo é criar outros projetos dentro da nossa solução e deixar cada um com sua respectiva responsabilidade.

Vamos criar os projetos:

  • Api: Irá conter as chamadas das nossas APIs.
  • Domain: Irá conter as entidades do nosso sistema (Dominios Ricos).
  • Repository: Onde será realizado as interações de persistência.
  • Service: Onde será realizado a regra de negócio em caso necessário.

Cada classe criada dentro da service e repository terá seu respectivo contrato (Interfaces).

Criando os projetos:

Clique com o botão direito em cima da Solution e crie um novo projeto.

Em seguida, selecione o projeto Biblioteca de Classes (Class Libary) e adicione o nome do projeto, lembrando que vamos criar uma class libary para cada projeto mencionado.

No final, teremos essa estrutura:

Agora que nossos projetos estruturados já estão estruturados, vamos criar um controller chamado HeroContolle e um endpoint do tipo Post chamado HeroApi.

Esse endpoint irá receber alguns parâmetros, mas em vez de adicionar N parâmetros no escopo do método, vamos criar uma classe chamada HeroDto, um padrão de projeto para transferencial de dados entre camadas.

Nossa heroDto terá essa estrutura:

Agora que já temos nossa DTO, vamos criar nossa Model dentro do projeto Domain chamada Hero.

Note que em nossa classe tem um construtor, e o atributos dela são privados ou seja, um Hero só é criado dentro da classe Hero. Dessa forma, evito que meu objeto seja alterado no decorrer do processo.

Agora que já temos nossa model, vamos criar nossa classe service com o nome HeroService.

Note que vamos utilizar nesse momento o conceito de contratos (Interfaces). Basicamente, a service irá ter contratos para ser acessada, ou seja, nossa controller não conhece a HeroService. Ela conhece o contrato da classe. Se por algum motivo a classe HeroService for alterada, as camadas acima não são impactadas.

Vamos criar a interface IHeroServices, que contém apenas a assinatura do método, ou seja, a controler sabe que tem que chamar um IHeroService.Hero. Ela não sabe, porem, quem implementa essa interface. Dessa forma, começamos a isolar os pontos do sistema:

Agora vamos herdar nossa interface na classe heroService.

Dentro da services vamos adicionar a regra de negócio. Se o nome do hero for “Iron Man”, vamos adicionar uma lista de string, apenas para simular uma regra de negócio em nossa service.

Agora devemos criar a HeroRepository e ajustar a HeroService, utilizando o mesmos conceitos de interfaces.

Na repository não vamos nos aprofundar. Vou retornar apenas o hero. Nos próximos artigos, vamos utilizar o Dapper para realizar a persistência de dados.

Vamos voltar a HeroService e utilizar a IHeroRepository:

Note que criamos uma propriedade readOnly do tipo IHeroRepository e passamos ela para o construtor da classe, funcionando através da injeção de dependência do .Net Core.

Vamos fazer a mesma coisa na controller, só que agora vamos adicionar a service.

Por fim, para dar certo tudo que desenvolvemos até aqui, precisamos mapear na injeção de dependência do .net core para as interfaces criadas.

Vamos até a classe startup no método ConfigureServices para adicionar os Singletons:

Referencias do projeto:

Api: Referência — Service

Service: Referência — Domain e Repository

Repository: Referência — Domain

Domain: Não referencia Ninguém

Estrutura Final

Testes

Vamos ver se isso tudo deu certo. Abra o postman e execute o projeto:

O código está no meu GitHub. Confere lá.