Diferença entre Forward e Redirect no retorno do Controller do SpringMVC

        Nesse artigo vou mostrar a diferença entre o Forward e o Redirect em uma chamada para um Controller do SpringMVC que retorna a String com o endereço a ser chamado depois da ação. Além de retornar a String com a página a ser carregada você pode especificar como esse retorno vai ser feito usando as opções Forward e o Redirect concatenadas ao endereço: 

Forward:

- O forward é um encaminhamento interno, onde a mesma requisição é reenviada para outro controller ou endpoint no servidor.

- O forward é executado do lado do servidor, sem envolver uma nova requisição do cliente.

- O URL no navegador permanece o mesmo.

- Os dados da requisição original são preservados e podem ser acessados pelo controller ou endpoint de destino.

- É útil quando você deseja processar dados adicionais ou realizar ações no backend antes de exibir a próxima página.

Redirect:

- O redirect é uma resposta do servidor ao cliente para redirecioná-lo para um novo URL.

- O redirect envolve uma nova requisição do cliente para o novo URL.

- O URL no navegador é atualizado para o novo URL.

- Os dados da requisição original não são preservados. Eles devem ser passados através de parâmetros de URL, atributos de sessão ou armazenados em algum outro local persistente.

- É útil quando você deseja redirecionar o cliente para uma nova página, como após um cadastro bem-sucedido ou para evitar reenvio de formulários quando atualizar a página.

        No contexto específico onde você quer permanecer na mesma página de cadastro com os dados pré-preenchidos em caso de erro, o uso de forward é mais adequado. Ao retornar a String que representa a mesma página de cadastro, você está realizando um forward interno, mantendo os dados da requisição original e exibindo a mesma página com os dados pré-preenchidos.

Relacionamento bidirecional recursivo com JPA

           Neste artigo vou mostrar um exemplo de um relacionamento bidirecional recursivo, ou seja, o objeto faz referência a ele mesmo. 

As vezes ao invés de usar herança, essa solução resolve de forma mais simples não tendo que alterar muita coisa no modelo já existente. Recentemente usei ela para o desdobramento de uma entidade que era a base do sistema e foi reclassificado em elementos "pai e filho". 

Claro que houve a necessidade de aumentar alguns campos na tabela que serão usados apenas quando for "filho" ou "pai", mas a desnormalização do modelo muitas vezes se faz necessário. O uso de outra solução acarretaria em uma grande mudança em todo o sistema. 

Para o exemplo vamos pensar para fins didáticos em uma cadeia de comando onde um Chefe tem Subordinados, mas também está subordinado à um Chefe.

 

No banco existem os seguintes campos: id, nome e chefe_superior_id. Segue o código:

 

 

import javax.persistence.*;

import java.util.List;

 

@Entity

@Table(name = "chefe")

public class Chefe {

 

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;

 

    @Column(name = "nome")

    private String nome;

 

  @OneToMany(mappedBy = "chefe", cascade = CascadeType.ALL, fetch = FetchType.LAZY)

    private List<Chefe> subordinados;

 

    @ManyToOne

    @JoinColumn(name = "chefe_superior_id")

    private Chefe chefe;

 

    // getters e setters

 

}