Validação e arquitetura JAVA

Programação Java
#1

Tenho uma dúvida em relação à validação em uma aplicação web JAVA.
A validação deve ficar no objeto de negócio. Certo?
Mas como ficam as validações que dependem de banco de dados? Por exemplo não poder cadastrar dois clientes com o mesmo nome? Ficam no DAO? Na camada de serviço? Por quê?

Obrigado!

#2

[quote=ricardo.ekm]
Mas como ficam as validações que dependem de banco de dados? Por exemplo não poder cadastrar dois clientes com o mesmo nome? Ficam no DAO? Na camada de serviço? Por quê?

Obrigado![/quote]

Eu criaria regras no banco de dados(algo como UNIQUE,no caso do exemplo) e trataria as exceções geradas em código mesmo(DAO) podendo filtrar os SQLCODEs se nescessário,caso queira tratar somente alguns casos.
Além disso,deve-se validar os objetos de negócio e,quando não for possível,validar na camada de serviços,como é o caso do exemplo.

#3

Então o meu objeto de negócios conhece o DAO? Eu injeto o DAO nele?
Mas e ai, e para salvar? Ele mesmo se salva?

#4

Obrigado pelas respostas Maracujá. Pode me ajudar a clarear um pouco?
Estou trabalhando com beehive (baseado no struts) então tenho para salvar um cliente, por exemplo, tenho um form que chama uma action no meu controller com um form bean.Minha dúvida é, quem eu chamo no meu controller? O dao diretamente? Ou crio uma camada de serviço que tem um método save que recebe um objeto cliente como parâmetro e faz a validação e depois faz uma chamada ao DAO? Ou alguma outra coisa?

Estou um pouco confuso quem é responsável por persistir minhas entidades e como isso se relaciona com a validação :?

Obrigado.

#5

[quote=ricardo.ekm]Tenho uma dúvida em relação à validação em uma aplicação web JAVA.
A validação deve ficar no objeto de negócio. Certo?
[/quote]

Não.
O que fica no objeto são consistencias.
As valdiações ficam num objeto de validação.

Tudo fica no objeto de validação que vc usa assim

Validator clienteValidator = ...

ValidationResult result = clienteValidator.validate(cliente);

if (!result.isValid()){
   // enumera razões
   for (InvalidationReason r : result){
        System.out.println(r.toString());
  }
}
#6

Depende da validação. Se for uma regra de negócio ela deve ser validadada objeto de negócio, que não pode aceitar qualquer coisa que quebre seu contrato.

No seu exemplo você poderia fazer com que o erro seja detectado na criação do objeto (talvez com uma fábrica que verifica se o objeto pode ser criado) ou no DAO, que lança uma exceção quando o objeto inválido é persistido. Como não faz sentido você tentar persistir algo que você já sabe que é inválido a primeira opção parce mais sensata.

#7

Dúvida. Usando um framework, como por exemplo o VRaptor, ele próprio vai chamar o construtor padrão do meu pojo e depois os “setters”, ao invés de chamar um construtor com as informações (acredito eu que funcione desta forma). Neste caso como eu detectaria o erro na criação do objeto?

#8

Nenhuma idéia, falei besteira ou o tópico se perdeu?

#9

Interessante a abordagem da fábrica. Na segunda opção, do DAO lançar a exceção não seria errado a camada de persistência conhecer alguma regra de negócio como ter dois clientes repetidos? Ou nada a vê isso?
Quem no caso chamaria a fábrica, o meu controler? Ou meu controler faria uma chamada a uma camada de servico que eu criaria no caso?
Para que afinal eu preciso de uma camada de serviço? Apenas para gerenciar a transação? As vezes fico criando uma camada de serviço com métodos que só encapsulam um método no DAO.

Zinho acho que neste caso não tem como, alguem sabe mais sobre isso?

#10

Olha para mim não poder ter dois clientes iguais cadastrados (pelo CPF ou RG) seria uma regra negocial, portanto acho, sob meu ponto de vista, vc ter um local onde vc pudesse ter as regras de negócios (separação em camadas) um BO (Business Object) por exemplo, então antes de inserir vc faz a verificação no banco de dados antes, se o cliente ja estiver cadastrado, mostre uma mensagem ao usuário.

Espero que ajude.

[]'s

#11

Olha, se vc estiver usando algum mecanismo de DI pode usar a injeção sim, ou vc poderia usar uma Factory (Abstract Factory, Factory Method) que produzi-se os seus DAO, utilizando o DAO para a consulta e também para a persistência deste objeto. Lembre-se, acesso a dados é com DAO msm.

#12