APIs Data Driven com ASP.NET Core 3.0 e EF Core 3.0 - Part 1

Não existe bala de prata

Eu sou um defensor da orientação a objetos e de domínios ricos. Mesmo assim, gosto de pontuar que não existe bala de prata no desenvolvimento de software, ou seja, o DDD não atende a tudo.

Em determinados momentos, você quer algo data driven, apenas um CRUD básico sobre o banco, sem criar complexidade desnecessária. Caso contrário, não sobra tempo para focar no seu domínio ou mesmo para testá-lo.

Se quiser entender melhor quando escolher cada abordagem, leia o artigo sobre Data Driven vs Domain Driven. Em resumo, cadastros simples, como categorias ou unidades de medida, raramente justificam um domínio rico.

Por isso, neste artigo, vou mostrar como criar APIs data driven de forma simples, prática e objetiva. Com isso, você economiza um belo tempo de desenvolvimento nas partes do sistema que não têm regras de negócio relevantes.

A entidade de produto

A próxima entidade é o Product.cs, que se parece com a categoria. A diferença é que ele contém duas propriedades para referenciá-la: o CategoryId e o Category.

using System.ComponentModel.DataAnnotations;

namespace Shop.Models
{
    public class Product
    {
        [Key]
        public int Id { get; set; }

        [Required(ErrorMessage = "This field is required")]
        [MaxLength(60, ErrorMessage = "This field must contain between 3 and 60 characters")]
        [MinLength(3, ErrorMessage = "This field must contain between 3 and 60 characters")]
        public string Title { get; set; }

        [MaxLength(1024, ErrorMessage = "This field must contain at most 1024 characters")]
        public string Description { get; set; }

        [Required(ErrorMessage = "This field is required")]
        [Range(1, int.MaxValue, ErrorMessage = "Price must be greater than zero")]
        public decimal Price { get; set; }

        // Chave estrangeira da categoria
        [Required(ErrorMessage = "This field is required")]
        [Range(1, int.MaxValue, ErrorMessage = "Invalid category")]
        public int CategoryId { get; set; }

        // Propriedade de navegação, opcional neste cenário
        public Category Category { get; set; }
    }
}

Se você não usa outras informações da categoria além do Id, a propriedade de navegação Category não é necessária. Por outro lado, se quiser carregar os dados da categoria junto com o produto, ela passa a ser obrigatória.

Resumo das anotações

Você deve estar se perguntando o que significa esse monte de anotações sobre as propriedades. Então, aqui vai um guia rápido:

• Key: define que a propriedade é uma chave.
• Required: define que o campo é obrigatório.
• MaxLength: define um tamanho máximo, em caracteres, para o campo.
• MinLength: define um tamanho mínimo, em caracteres, para o campo.
• Range: define um limite numérico mínimo e máximo para o campo.

Nas APIs data driven, essas anotações fazem boa parte do trabalho que um domínio rico faria.

Além disso, o parâmetro ErrorMessage personaliza a mensagem que o cliente recebe quando a validação falha. Dessa forma, o front-end consegue exibir um retorno claro para o usuário.

Registrando o contexto no Startup

Por fim, precisamos informar à aplicação que usamos o EF Core, um banco em memória e o nosso DataContext. Fazemos isso no método ConfigureServices do arquivo Startup.cs, com o método AddDbContext.

O ConfigureServices configura os serviços que a API utiliza, como autenticação, logs e banco de dados. Assim, basta chamar o AddDbContext, informar o contexto e dizer, nas opções, que queremos um banco em memória:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Shop.Data;

namespace Shop
{
    public class Startup
    {
        // ...

        public void ConfigureServices(IServiceCollection services)
        {
            // Banco em memória chamado "Database"
            services.AddDbContext<DataContext>(opt => opt.UseInMemoryDatabase("Database"));
            services.AddControllers();
        }

        // ...
    }
}

Ao usar um banco em memória, precisamos dar um nome a ele. Neste caso, chamei de "Database", mas qualquer nome funciona.

Quando você migrar para o SQL Server, basta trocar o UseInMemoryDatabase pelo UseSqlServer com a connection string. O restante das APIs data driven continua igual, porque o contexto isola essa decisão.

O custo de abrir conexões

No .NET, temos o using, que garante o descarte de um objeto logo após o uso. Porém, o using trabalha em blocos, então várias chamadas ao banco significam conectar e desconectar diversas vezes.

Cada conexão com a API ou com o banco tem um custo mínimo. Afinal, há a abertura, o estabelecimento de um canal seguro, a transferência e a conferência dos dados e, por fim, o fechamento.

Portanto, quanto menos idas desnecessárias ao banco fizermos, mais rápida fica a API data driven. Mas, se não podemos usar o using em todo lugar nem correr o risco de deixar conexões abertas, o que fazer?

Um contexto por requisição

A solução é criar um objeto do DataContext a cada requisição à API. Inicialmente, ele não se conecta ao banco, apenas existe na memória.

Quando a requisição precisa executar uma operação no banco, o contexto já está pronto. Então, o EF Core abre a conexão quando necessário e executa a instrução desejada.

Pouco depois, ainda na mesma requisição, precisamos ir ao banco de novo. Adivinha?

O mesmo contexto continua disponível para nos atender.

Ao terminar a requisição, o ASP.NET Core descarta esse objeto e libera os recursos associados. Tudo isso acontece sem a nossa intervenção, graças ao recurso de injeção de dependência do framework.

Declarando e resolvendo a dependência

Injetar dependência significa deixar explícito que dependemos de algo para trabalhar. Por exemplo, para criar um produto, precisamos do DataContext, afinal ele é a ponte entre a API e o banco.

Em outras palavras, o controller diz: "Para cadastrar um produto, eu preciso do DataContext; como você vai me prover ele, eu não sei".

No código, basta declarar o objeto no construtor da classe:

public class ProductController
{
    // O ASP.NET Core entrega o contexto pronto para uso
    public ProductController(DataContext context) { /* ... */ }
}

Assim, criamos uma dependência do DataContext no ProductController, o que faz todo sentido em APIs data driven. Sem um contexto, não conseguimos fazer nenhuma operação de produto no banco.

Uma coisa que você aprende em orientação a objetos é que devemos depender de abstrações, e não de implementações. O curso 1975 do balta.io aprofunda esse tema.

Agora, precisamos resolver a dependência, e isso também acontece no Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<DataContext>(opt => opt.UseInMemoryDatabase("Database"));
    // Um DataContext por requisição
    services.AddScoped<DataContext, DataContext>();
    services.AddControllers();
}

A linha com AddScoped resolve a dependência do contexto por requisição. Na prática, segundo a documentação do EF Core, o próprio AddDbContext já registra o contexto com esse tempo de vida, então a linha deixa a intenção explícita, mas não muda o comportamento.

Para saber mais sobre o tema, veja o artigo sobre injeção de dependência no ASP.NET Core.

Listando as categorias na API data driven

Para listar as categorias, precisamos ir ao banco e, portanto, precisamos do DataContext. Como vimos na seção de injeção de dependência, uma opção é recebê-lo no construtor:

using Microsoft.AspNetCore.Mvc;
using Shop.Data;

namespace Shop.Controllers
{
    [ApiController]
    [Route("v1/categories")]
    public class CategoryController : ControllerBase
    {
        private readonly DataContext _context;

        public CategoryController(DataContext context)
        {
            _context = context;
        }
    }
}

Porém, existe uma forma ainda mais simples. O ASP.NET Core oferece o atributo FromServices, que injeta um objeto já registrado diretamente no parâmetro do método.

Dessa forma, o método fica assim:

using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using Shop.Data;
using Shop.Models;

// ...

[HttpGet]
[Route("")]
public async Task<ActionResult<List<Category>>> Get([FromServices] DataContext context)
{
    // Lê todas as categorias de forma assíncrona
    var categories = await context.Categories.ToListAsync();
    return categories;
}

Para ler os dados na API data driven, basta chamar o contexto seguido da coleção. Como usamos métodos assíncronos, não podemos esquecer do await.

Note também que decoramos o método com HttpGet e deixamos a rota vazia. Para testar, rode a aplicação com dotnet run e acesse https://localhost:5001/v1/categories.

Como o banco começa vazio, a resposta inicial é uma lista vazia em JSON.

Repare que o endpoint inteiro cabe em poucas linhas, e essa é justamente a proposta das APIs data driven. Na próxima parte, vamos criar os métodos de cadastro para popular esses dados.