Dê o próximo passo e inicie sua carreira
Dê o próximo passo e inicie sua carreira agora mesmo
3 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
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:
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.
Avalie este artigo
