Pequenos ajustes, grandes mudanças!

Pequenos ajustes, grandes mudanças!

Uma das decisões arquiteturais que tomamos no desenvolvimento do novo site lançado no dia 1º de Março, foi deixar o site de vendas separado da plataforma de curso e também sem acesso ao banco de dados.

Devido a decisão de retirar o acesso do site de vendas ao banco de dados, precisávamos passar as informações necessárias para o site de alguma forma. Optamos então por expor uma API que é consumida pelo site.

Vamos pegar um endpoint da API como exemplo:

Banner da Escola de Programação: Matricula-se na escola de Programação. Junte-se a uma comunidade de mais de 500 mil estudantes. Na Alura você tem acesso a todos os cursos em uma única assinatura; tem novos lançamentos a cada semana; desafios práticos. Clique e saiba mais!

Um dos endpoints da nossa API é responsável por listar apenas o nome (nome do curso na plataforma) e o slug (nome da url do curso formatado para efeito de SEO) de todos os cursos.

Já tínhamos uma classe que representa um curso com as informações necessárias:


@Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
@Vetoed @Entity public class Course implements Identifiable,Product { 
@Id @GeneratedValue 
private Long id;

@NotNull @Length(min = 3, max = 255) 
private String name;
private String urlName; // Um monte de outras informações }

Porém, repare que a classe Course tem informações que não precisávamos expor neste endpoint.

A princípio, era só excluir os campos desnecessários na hora de montar o JSON para a API. Porém, havia um detalhe nessa abordagem: todas as vezes que acrescentássemos um campo novo na classe Course, teríamos que lembrar de excluir esse novo campo nos endpoints desnecessário, ou seja, uma solução problemática... Percebendo que a nossa API iria ficar muito sensível a qualquer alteração no nosso modelo de curso, resolvemos criar uma classe nova que conteria somente informações necessárias para o endpoint.


@Vetoed public class SimpleCourse {

@SerializedName("slug") private final String urlName;

@SerializedName("nome") private final String name;

@SerializedName("quantidade_aulas") private final long totalSections;

@SerializedName("minutos_video") private final int duration; }

Com esse pequeno ajuste, conseguimos gerar o nosso JSON com apenas os campos necessários. E se for necessário adicionar/modificar algum campo no endpoint? Basta apenas ajustar o campo na classe SimpleCourse que o JSON será construído apenas com os campos dessa classe! Uma solução simples que nos livra de toda responsabilidade de ficar se preocupando com qualquer tipo de modificação!

Essa solução é um Design Pattern chamado DTO (Data Transfer Object), que tem apenas a finalidade de armazenar os dados necessários que precisamos transferir, ou seja: uma classe sem qualquer regra de negócio que será utilizada apenas para transferir os dados que queremos!

O que acharam da nossa solução? É a primeira vez que viu sobre o DTO? Deixe seu comentário sobre o que achou dessa abordagem para resolver esse endpoint.

Você pode aprender isso e mais com nossos cursos de programação.

Veja outros artigos sobre Programação