Padrões de desenvolvimento JSF

Gosto da terceira abordagem.

tópico interessante, vou acompanhar os geeks em jsf dizerem ai…

tambem achei muito interessante, vou acompanhar

Particularmente eu tenho uma entidade pro banco, o DAO, Business, um Bean para a tela aqui ficou padronizado como TO, o Handler e a página.

Tudo separado, no caso uso EJB aqui no trabalho tbm.

Eduardo Bregaida:

Particularmente eu tenho uma entidade pro banco, o DAO, Business, um Bean para a tela aqui ficou padronizado como TO, o Handler e a página.

Tudo separado, no caso uso EJB aqui no trabalho tbm.

Como seria esse Handler e qual a função dele?

Opção 3 pq geralmente oq está sendo passado vai ou está vindo do banco de dados.

Geralmente a terceira abordagem.

com JPA voce não nescessita de um DTO.

E geralmente utilizo o pattern enterprise “ViewHelper” para separar a logica do managed bean dos atributos da view.

raf4ever:

Eduardo Bregaida:

Particularmente eu tenho uma entidade pro banco, o DAO, Business, um Bean para a tela aqui ficou padronizado como TO, o Handler e a página.

Tudo separado, no caso uso EJB aqui no trabalho tbm.

Como seria esse Handler e qual a função dele?

O Handler é o ManegedBean, no caso ele tem os métodos que minha tela executa.

Eduardo Bregaida:

raf4ever:

Eduardo Bregaida:

Particularmente eu tenho uma entidade pro banco, o DAO, Business, um Bean para a tela aqui ficou padronizado como TO, o Handler e a página.

Tudo separado, no caso uso EJB aqui no trabalho tbm.

Como seria esse Handler e qual a função dele?

O Handler é o ManegedBean, no caso ele tem os métodos que minha tela executa.

O que mata no projeto aqui é não poder usar JPA, pois tudo é procedure executada no DB2 MainFrame… :roll:

Uso a terceira abordagem.

eu tb uso a opção 3.
mas complementando a pergunta, seria bom saber o que vcs usam para separar a lógica do managed bean??

alves.Felipe:

eu tb uso a opção 3.
mas complementando a pergunta, seria bom saber o que vcs usam para separar a lógica do managed bean??

Services quando são necessários(não como meros delegates),ou DAO’s sendo injetados pelo Spring acessando diretamente o controller.

raf4ever:

Services quando são necessários(não como meros delegates),ou DAO’s sendo injetados pelo Spring acessando diretamente o controller.

alves.Felipe:

raf4ever:

Services quando são necessários(não como meros delegates),ou DAO’s sendo injetados pelo Spring acessando diretamente o controller.

mas por exemplo. Existe um mb PedidoMB, nele eu tenho um método salvar, porém antes de salvar eu preciso fazer algumas validações:
1- validar prazo do cliente
2- validar limite de crédito do cliente.
3 - mais N validações;
como que ficaria sua arquitetura neste cenário ?

Colocaria as validações no model e o MB acessaria.

alves.Felipe:

Ficaria assim então as classes?

PedidoMB 
--
PedidoNegocio (validações)
Pedido (entidade)
--
PedidoDao

e se tiver usando Spring para injetar as dependências, meu PedidoNegocio estaria definido como Service?

PedidoNegocio n eh necessaria(as validações podem ficar em Pedido)

E eu anoto todas as classes gerenciadas pelo Spring(controllers,services e daos) como @Component,
não vi na prática a diferença entre usar @Controller,@Service e @Repository.

blz tirou minha dúvida, mas acho que fica meio estranho… todas minhas “trocentas” validações na minha entidade.
E tb é certo chamar uma consulta (ClienteDao, por exemplo) de dentro da entidade Pedido ? supondo que eu precise consultar
alguns dados para a minha validação.

Nossa !

Não achei que o tópico geraria tanta discussão.

Minha opnião:

Em relação as 3 forma apresentadas, a que eu constumo usar é a segunda, ou seja criando as classe DTO. O problema dessa solução é que ela gera um certo trabalho, pois quando se vai persistir um objeto é necessário preencher a entity com os valores do DTO.

A segunda forma é uma boa solução, porem exitem telas que os dados a serem preenchidos não fazem parte do modelo e nesse caso a variação da primeira e da segunda forma poderiam ser usadas. O que determina qual forma usar é a quantidade de parâmetros.

alves.Felipe:

blz tirou minha dúvida, mas acho que fica meio estranho… todas minhas “trocentas” validações na minha entidade.

Mas não há problema nisso,eh justamente no Model onde as validações devem estar.

raf4ever:

alves.Felipe:

blz tirou minha dúvida, mas acho que fica meio estranho… todas minhas “trocentas” validações na minha entidade.

Mas não há problema nisso,eh justamente no Model onde as validações devem estar.

Rafael,

como seriam essas validações nas entidades?

poderia fazer dessas formas?

Forma 1 - Hibernate Validator

@NotNull(message="Campo obrigatório)
private String nome;

Forma 2 - Criando suas proprias exceptions

private Double saldo;

 public void saldo(saldo) {
        if(saldo < 0) {
            throw new MinhaException();
        } else {
            this.saldo = saldo;  
        }
    }
}

Tem mais alguma forma??
Alguma forma recomendada??