Eu tenho a classe usuario
[code]public class Usuario {
private String user;
private String pass;
// getters && setters
}[/code]
esse ai é um MODEL, certo?
e estou numa pagina (VIEW) de login…
A validação se a senha enviada pelo usuario atraves da VIEW esta correta ou não… deve ser feita por um METODO na classe de Usuario…
Ou a validação tem que ser feita no Controller??
Se você vai validar os dados digitados pelo usuário, eu faria no controller mesmo. Muitos frameworks MVC já dão suporte à isso.
VALIDAÇÃO DE LOGIN / SENHA, só deixando claro…
Tudo bem, qualquer validação de dados da tela eu acho válido fazer no controller, agora regras de negócio, aí não.
entao o Usuario deve ter um metodo “logar”?
é isso?
Pq achava que isso deveria ficar no Controller
onde ele receberia os parametro enviados pelo browser e fazia um tipo
[code]public class Controller {
public boolean logar(){
if(parametroenviado.getUsuario.equals(objeto.getUsuario()) &&
parametroenviado.getSenha.equals(objeto.getSenha())){
return true;
} else {
return false;
}
}
}[/code]
ou não é assim?
bom, você pode validar os dados no controller e depois invocar algum serviço de login, ex:public void logar(){
if(/* dados de login estão válidos */){
loginService.logar(usuario);
}
}
[quote=faeldix]entao o Usuario deve ter um metodo “logar”?
é isso?
Pq achava que isso deveria ficar no Controller
onde ele receberia os parametro enviados pelo browser e fazia um tipo
[code]public class Controller {
public boolean logar(){
if(parametroenviado.getUsuario.equals(objeto.getUsuario()) &&
parametroenviado.getSenha.equals(objeto.getSenha())){
return true;
} else {
return false;
}
}
}[/code]
ou não é assim?[/quote]
Partindo do princípio de que devemos atribuir comportamentos nos objetos que efetuam o mesmo, acredito que colocar o método logar no model é o mais correto, porque afinal “logar-se” é um papel do usuário…
Pra abstrair um pouco, podemos dizer que Model vai ser a “pele” do seu sistema, onde vai receber os dados.
O controller vai fazer a validação e atribuir os dados para os Models condizentes, para que os mesmos terminem o serviço…
Imagine que o Model sempre deve receber os dados corretos, para apenas aplicar a regra de negócio sem se importar com validações. Podemos dizer que o Model deve confiar no que recebe do Controller…
É melhor fazer como o Rodrigo Sasaki sugeriu. Encapsule a autenticação num serviço.
Quanto a validações, num modelo OO tradicional os teus objetos devem obedecer a invariantes, pré e pós condições (o que está bem descrito em Fundamentals of Object-Oriented Design in UML - Page Jones). Ou seja, o teu objeto nunca deveria entrar num estado inconsistente (faça validações no construtor e nos métodos que alteram o estado do objeto).
Entretanto eu nunca implementei dessa maneira. :lol: Integrar isto com frameworks de persistência e frameworks MVC é complicado, por que normalmente manter o objeto num estado inconsistente é conveniente (o framework, automaticamente, instancia teus objetos com valores inseridos num formulário, por exemplo). Me parece ser este o motivo para as validações serem chamadas no controlador (elas efetivamente estão num objeto especializado).
No fórum do SpringMVC teve uma discussão semelhante há um tempo atrás:
[quote=Rodrigo Sasaki]bom, você pode validar os dados no controller e depois invocar algum serviço de login, ex:public void logar(){
if(/* dados de login estão válidos */){
loginService.logar(usuario);
}
}[/quote]
Eu acho que é mais interessante fazer justamente o contrário. Eu acho mais fácil criar um serviço que verifique usuário/senha e retorne um objeto Usuario válido, e então deixar o controlador criar uma sessão.
[quote=wagnerfrancisco]É melhor fazer como o Rodrigo Sasaki sugeriu. Encapsule a autenticação num serviço.
Quanto a validações, num modelo OO tradicional os teus objetos devem obedecer a invariantes, pré e pós condições (o que está bem descrito em Fundamentals of Object-Oriented Design in UML - Page Jones). Ou seja, o teu objeto nunca deveria entrar num estado inconsistente (faça validações no construtor e nos métodos que alteram o estado do objeto).
Entretanto eu nunca implementei dessa maneira. :lol: Integrar isto com frameworks de persistência e frameworks MVC é complicado, por que normalmente manter o objeto num estado inconsistente é conveniente (o framework, automaticamente, instancia teus objetos com valores inseridos num formulário, por exemplo). Me parece ser este o motivo para as validações serem chamadas no controlador (elas efetivamente estão num objeto especializado).
No fórum do SpringMVC teve uma discussão semelhante há um tempo atrás:
Assim, eu nunca ouvi falar em OO tradicional x OO moderna ou qualquer coisa do tipo. Isso que você escreveu é uma verdade: objetos devem ser criados em estados consistentes e devem ser mantidos consistentes durante sua existência. O problema é que o pessoal confunde validar estado de objetos com validar digitação de usuário, que são coisas completamente diferentes.
Por exemplo, você pode criar a seguinte classe no seu modelo:
class Poupanca{
public Poupanca(double saldoInicial){
if(saldoInicial <= 0.0) throw new IllegalArgumentException("saldo inicial deve ser maior que zero");
}
}ou seja, assim eu garanto que qualquer objeto Poupanca será um objeto válido. Repare que esta classe não tem idéia alguma sobre como a informação de saldoInicial será passada. Ela apenas exige que seja um double. O simples fato de exigir um double, já garante por exemplo, que você não vai receber um texto ou um PDF.
Assim, no Model, devemos garantir a consistência dos objetos para que as regras de negócio sejam cumpridas efetivamente.
Bom, mas isso significa que a View não precisa fazer validações ? Definitivamente não! Muitos programadores costumam menosprezar a importância da View (já fui assim), mas os artefatos que compõe a View tem uma responsabilidade muito grande, que é fazer a interface com o usuário. Sendo assim, a View precisa orientar o usuário sobre o uso correto do sistema, e isso inclui fazer com que o usuário informe os dados corretamente. Entre os tipos de validação que podem ser feitas: evitar que campos numéricos recebam texto, verificar formatação de datas, campos obrigatórios, etc. Porém, aqui cabe uma observação: nem sempre você poderá fazer esse tipo de validação na View. No caso de trabalhar com HTML puro por exemplo, você vai precisar transferir essa responsabilidade para o controller. De qualquer maneira, o Controller precisará converter os parâmetros passados em HTML em objetos Java, prontos para que sejam usados pelo Model.
Justo, eu me expressei mal. Na verdade quis dizer num modelo OO correto ao invés de tradicional. 
Concordo contigo. O ponto é que alguns frameworks de persistência e frameworks mvc que fazem binding com formulários, por exemplo, exigem construtores vazios, getters/setters mais simples (que não façam validações) e coisas do tipo.
Daí eu vejo duas possibilidades:
Como você lida com isso? Aqui eu me refiro às validações de digitação, campos obrigatórios, coisas do gênero.