[quote=CodeDeveloper]sergio,
Realmente você citou a composição, desculpe-me. Analisei o link passado e acho entendi o que você quis dizer.
Veja se a abordagem está correta, por favor:
De modo geral, a idéia é ter uma classe que valide Livro, centralizando as regras de validações e utilizando um validador.
public class LivroValidador{
public boolean isValid(Livro livro){
// Utilizar aqui o Validar e centralizar as regras de validação
}
}
Então, utilizar essa classe em todos os pontos necessários para garantir a persistencia, como por exemplo em LivroDAO, CadastroController e etc.
public class CadastroController extends HttpServlet{
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
Livro livro = new Livro(req.getParameter("nome"),req.getParameter("valor"));
// Utilização da classe validadora
if(new LivroValidador.isValid(livro)){
new LivroDAO.salvar(livro);
}
}
}
public class LivroDAO{
public void salvar(Livro livro){
// Utilização da classe validadora
if(new LivroValidador.isValid(livro)){
//executa o insert no banco
}
}
}
1º: Entendi corretamente, sergio?
[/quote]
Sim. O único ponto que faltou é que não é o mesmo validador que vc usa em todo o lugar porque as regras que vc está validando em cada camada são diferentes. O DAO por exemplo vai validar se o campo está preenchido, mas ele não sabe validar se o valor preenchido é correto conforme a regra de negocio. Isso é o que o service vai fazer. Em geral eu mantenho validadores de persistencia, que só uso nos daos e validadores de dominio que uso nos services. As regras dos validadores de dominio são realmente regras, as dos do DAO são salvaguardas (safety-check)
Não. Um validador que retorna um validador ? Ou seja, um objeto que se retorna a si mesmo ?
Um opção mais robusta é usar um método validate que não retorna um boolean. Retorna um objeto de resultado da validação (ValidationResult) e esse objeto que tem um isValid(). Lembre-se que quando o objeto não é válido, a razão de invalidação é mais importante que o boolean, normalmente vc vai querer ter acesso a essas razões. Essas razões ficam no ValidationResult numa simples lista ou coisa assim ( no link que eu passei do javabuilding tem a implementação de um ValidationResult relativamente sofisticado que vc pode usar como modelo). O ponto é, isValid é pouca informação. Codigo verdadeiros têm um else que mostra ao usuario o problema.
public class CadastroController extends HttpServlet{
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
Livro livro = new Livro(req.getParameter("nome"),req.getParameter("valor"));
// Utilização da classe validadora
LivroValidator validator = new LivroValidator();
ValidationResult result = validator.validate(livro);
if(result.isValid()){
new LivroDAO.salvar(livro);
} else {
// mostra os erros para o usuario
resp.setAtribute(result.getInvalidationReasons().get(0).getMessage()); // pega a mensagem da primeira razão de invalidação
}
}
}
Só a camada de ui que pode diretamente mostrar as mensagens.
Na camada de serviços e de dao o else gera uma Exception ( normalmente uma ValidationException que contém o objeto ValidationResult).
O ponto é que são as mensagens que são importantes e não se é válido ou não. Ou seja, é mais importante saber porque é inválido, do que saber que é válido.