Validação de campos. Quando fazer?

tem uma coisa que o meu professor sempre diz, o que é banco é o administrador de banco que é responsavel por fazer isso e o que é aplicação a aplicação tem que fazer o papel dela

Ah isso sim, mas não to falando que o DAO vai fazer validação… quero saber se primeiro crio o objeto “cliente” e dentro da classe cliente eu tenho um metodo que valida os campos, ou seu na classe controle eu tenho os metodos de validação e só depois de validados eu gero o “cliente” e peço pro DAO grava-lo no banco!

ao meu ponto de vista, o ideal seria vc fazer as validações na aplicação criando os objetos e mandando para o banco, vc esta fazendo o seu projeto em que?

Na minha opinião essa validação tem de ser feita assim que o usuário digita o CPF (no textField Leave por exemplo)…
Pois é uma informação que não pode entrar errada no banco de dados e nem no programa…

resposta é DEPENDE kkkkkk

Conceitualmente existem 3 tipos de validações:

1) Regra de negócio
Esse tipo de validação condiz com as regras de negócio do domínio da solução. Exemplo: Cliente é um campo obrigatório na gravação de um nota fiscal. Esse tipo de validação deve estar centralizada normalmente na camada de negocio da aplicação. Mas pode ser centraliza em outro lugar caso a aplicação seje desprovido dessa camada…dai vai para a camada de visão (sem reutilização nehuma) ou vai para o banco de dados (mais indicado para estes casos, por pode ser reutilizada)

2) Campo de GUI
Campos de interface gráfica são aqueles campos que q devem ser validados por questões lógicas, não se atendo a nenhuma regra de negócio. Exemplos: Dentro um GUI de listagem o usuário não pode colocar a data final antes da data inicial
Esse tipo de validação deve estar centralizada na própria camada de visão.

3) Consistência de valores
Validar consistência de valores digitadas dentro dos campos, juntamente com suas mascaras. Por exemplo…validar se um CPF é um CPF valido, validar de um data é uma data valida.
Esse tipo de validação deve estar centralizada na própria camada de visão.

Qualquer confusão destes conceitos pode resultar numa implementação inflexível e sem reutilização.

Ótima resposta!!
Isso que é bom, eu que não tinha nada que ver com o assunto já acabei aprendendo!

Fernando obrigado pela resposta.

Eu fiquei com a duvida pois estou fazendo um projeto na faculdade referente a uma Locadora de carros, e no nosso diagrama de classes o metodo “validarCpf()” ficou dentro da classe ClientePf… o que eu entendi foi que quando eu desse os gets nas textfields eu iria verificar a consistencia dos daods (se contem 11 digitos e se só contem numeros) e depois, quando eu criasse o objeto cliente já com todos os dados validados, eu chamaria o validarcpf antes de gravar no banco, caso houvesse algum erro, apenas mostraria uma msg e continuaria na mesma tela para que o user arruma-se o campo errado.

Pra mim eu poderia fazer essa verificação de cpf antes de criar o objeto cliente em si, porém como o metodo consta na classe cliente, a duvida persistiu =P

Spotik:

Fernando obrigado pela resposta.

Eu fiquei com a duvida pois estou fazendo um projeto na faculdade referente a uma Locadora de carros, e no nosso diagrama de classes o metodo “validarCpf()” ficou dentro da classe ClientePf… o que eu entendi foi que quando eu desse os gets nas textfields eu iria verificar a consistencia dos daods (se contem 11 digitos e se só contem numeros) e depois, quando eu criasse o objeto cliente já com todos os dados validados, eu chamaria o validarcpf antes de gravar no banco, caso houvesse algum erro, apenas mostraria uma msg e continuaria na mesma tela para que o user arruma-se o campo errado.

Pra mim eu poderia fazer essa verificação de cpf antes de criar o objeto cliente em si, porém como o metodo consta na classe cliente, a dúvida persistiu =P

Ola Spotik

Eu entendo sim…vc não é primeiro e sera o ultimo, na verdade 90% da empresas que eu chego esse assunto esta completamente embaralhado kkkk
A “forma de bolo”, é baseado em responsabilidade, uma vez que uma definição arquitetural esta relacionado com RESPONSABILIDADE-> “quem deve fazer o que dentro da solução”…Tudo um questão de organização:

1) A camada de visão é responsável em validar os seguintes condições:
*) validar campos obrigatório de GUI - dentro das interfaces gráficas podem existir campos obrigatório pertences a lógica da própria GUI, sem estar relacionado com regra de negócio.
Exemplo: preenchimento obrigatório de data inicial e data final de um relatório entre datas.

*) consistência dos dados - validar o tipo das informações esperadas a ser inseridos pelos usuários: numero, data, hora, cpf, cnpj, e sua consistências gerais.
Por exemplo:

• validar se o usuário digitou apenas números em um campo no qual se espera um código de produto.
• validar se o usuário digitou uma data valida em um campo no qual se espera alguma data valido do mundo real.
• validar que a data final não pode ser anterior a data inicial na geração de um relatório entre datas.

*) Colocar e retirar as mascaras - a camada de visão deve pegar a informações bruta vindo de outras camadas e colocar as devidas mascaras antes de apresentar para o usuario final. Da mesma forma fazer o inverso, retirando as mascaras na hora de submeter a informação bruta para as outras camadas.

2) A camada de negócio é responsável em validar os seguintes condições:

*) consistência de negócio e/ou processo de negócio - validar se as informações brutas vindouras das outras camadas estão de acordo com as regras de negócio da solução.
Por exemplo:

• validar a obrigatoriedade de um CPF novo ou existente para gerar um nota fiscal.
• validar se um determinado CPF pode ou não estar fazendo uma nota fiscal acima do valor faturado.
• validar se uma nota fiscal pode ser emitido numa determinada data.

Obsversão
perceba em ambas as camadas visão e negocio pode existir validações de obrigatoriedade e consistência. O questão é quando vc coloca numa a responsabilidade da outra…OU seja o desenvolvedor implementa dentro do negocio uma validação de Tela ou dentro da tela a validação de negocio…e é ai que inflexibilidade começar a entrar no seu projeto…

Como usar?

• Procure classificar a validação…
  “Isso é a validação de GUI ou de negocio?”

Fernando, eu particularmente faço minhas validações da seguinte maneira:

public class GUIAluno extends JFrame {

    public GUIAluno() {

        JTextField textfieldCPF = new JTextField(new SomenteNumerosDocument());
    } 

    private class SomenteNumerosDocument extends PlainDocument {
        // crio meu documento onde meu textfield só aceitará números, por exemplo.
    }
}

public class DSOAluno {

    public String validarAluno(Aluno entityAluno) throws QualquerException {

        // se há erro, retorno uma mensagem específica a ser exibida na tela.
        String mensagem = "CPF inválido!"; // após realizar a validação do mesmo.
        return mensagem;
    }
}

Sacou a ideia?
Espero ter ajudado, abraços!

Ok…esta dentro da camada de visão.

Aqui não…validação de camada de visão para aplicativos web deve ser feitas dentro da camada de visão usando componentes server-side . Protocolo HTTP e javascript podem ser manipulados. Ja discutimos isso muito aqui…(pesquise a respeito)

Pelo seu descritivo é regra de negocio…
Não tenho como sugerir aonde vc vai colocar sua regra…fica a seu critério…

Veja que validar agente sempre valida…a questão é “foi validado no lugar correto ?” Caso não, flexilidade vai para o vinagre e bem vindo o engessamento…

A coisa é simples mas é complexa hahaha!

Mas eu entendi o basico. A validação basica de tipo, numero de chars, e tudo mais normalmente deve ser feita na view, já as regras essenciais para o negocio na model msm!

Spotik:

A coisa é simples mas é complexa hahaha!

Mas eu entendi o basico. A validação basica de tipo, numero de chars, e tudo mais normalmente deve ser feita na view, já as regras essenciais para o negocio na model msm!

Bom, no meu caso to aplicando mvc, então é a controle que vai fazer essa validação antes de jogar pra model certo?

MVC:

O modelo (model) é usado para definir e gerenciar o domínio da informação e notificar observadores sobre mudanças nos dados. Ele é uma representação detalhada da informação que a aplicação opera. A lógica de negócio adiciona valor semântico aos dados, e quando há mudança de estado o modelo notifica seus observadores. Por exemplo, aluno, professor e turma fazem parte do domínio de um sistema acadêmico. Operações como calcular a média final do aluno ou o índice de faltas da turma fazem parte da lógica de domínio. A forma como o dado é armazenado ou acessado não é de interesse do MVC, assume-se que é de responsabilidade do modelo.

A visão (view) apresenta o modelo num formato adequado ao utilizador, na saída de dados, e diferentes visões podem existir para um mesmo modelo, para diferentes propósitos.

O controlador (controller) recebe a entrada de dados e inicia a resposta ao utilizador ao invocar objetos do modelo, e por fim uma visão baseada na entrada. Ele também é responsável pela validação e filtragem da entrada de dados.

SIM