Na minha concepção, dados de domínio deve (claro que tudo depende do escopo)ser validados pelo model. Tomando essa afirmação como válida, eu acredito que validações do tipo: “teste,00” não é um inteiro válido, “58/67/-2009” não é uma data válida, e similares são validações de responsabilidade do controller. Porém em validação de um atributo IDADE > 0 e < 150, ao meu ver, é um dado de domínio, ou seja, a validação de uma entrada do usuário inicialmente é feita pelo controller que irá verificar se o valor digitado é um INTEGER (já que não temos um tipo NumerosNaturais no Java) se sim, esse INTEGER ainda deve estar dentro de um escopo que vai de 0 até no máximo 150. Nesse caso essa segunda validação deveria ser realizada pelo controller ou pelo model?
Eu acredito que meu model deveria ser mais ou menos assim:
public class Pessoa {
private int idade;
(...)
public void setIdade(int idade) {
if(idade < 0 || idade > 150) {
throw new IllegalArgumentException(RESOURCE.IDADE_INVALIDA);
}
}
}
Gostaria da opinião de todos, pois estavamos discutindo aqui sobre uma afirmação que lemos:"…é obrigação do controller enviar dados consistentes para o modelo…" e não chegamos a nenhuma conclusão. :?
isto depende… se a validação precisar de um mecanismo de persistencia então pode ser validado na model… porem se for somente entradas de dados do usuario… se for um sistema web a view pode assumir esta responsabilidade pois vc pode fazer estas validações apenas no client sem mandar a requisição para o servidor usando javascript, vbscript… pois assim vc tera um ganho em performace (mesmo que minimo) porem tera um ganho… pois assim só serão enviados para o servidor protocolos ja validados pelo cliente… isto poupa processamento do seu servidor…
É realmente interessante validar no banco tbm… pois alguem fazer inserções na base por fora da app… direto pelo sgdb dai se so validar no client tera uma puta dor de cabeça caso este alguem colocar dados inconsistentes…
[quote=luistiagos]isto depende… se a validação precisar de um mecanismo de persistencia então pode ser validado na model… porem se for somente entradas de dados do usuario… se for um sistema web a view pode assumir esta responsabilidade
[/quote]
Isso se você tem um escopo fixo do seu sistema. Agora e em um escopo indefinido ou indeterminado?
[quote=luistiagos]pois vc pode fazer estas validações apenas no client sem mandar a requisição para o servidor usando javascript, vbscript… pois assim vc tera um ganho em performace (mesmo que minimo) porem tera um ganho… pois assim só serão enviados para o servidor protocolos ja validados pelo cliente… isto poupa processamento do seu servidor…
[/quote]
Daí desabilitando a permissão de execução de Javascript do browser e te ferram?
[quote=Felagund]A validação deve ser feita em todos os niveis. Inclusive no banco.
Não valido no modelo, deixo para validar na base, apos validado no controller.
[]'s[/quote]
Isso significa que uma alteração me exige um trabalho multiplicado pelo número de mesmas validações espalhadas pelo sistema, sem contar que uma mudança de banco de dados seria um parto e se eu decidir persistir em um arquivo TXT não tenho como validar nada então?
[quote=luistiagos]É realmente interessante validar no banco tbm… pois alguem fazer inserções na base por fora da app… direto pelo sgdb dai se so validar no client tera uma puta dor de cabeça caso este alguem colocar dados inconsistentes…
[/quote]
Bem, nossas opiniões divergem porém cada um tem direito de expressar a sua. No meu caso eu não quero regras em banco de dados pois pra mim o banco é apenas um lugar para tornar persistente o estado em um determinado tempo do meu sistema, poderia ser um SGBD, um XML, um TXT, etc. Agora inclusões diretas em estruturas ustilizadas pela minha aplicação seria um problema de segurança e não de validação.
[quote=townray][quote=luistiagos]isto depende… se a validação precisar de um mecanismo de persistencia então pode ser validado na model… porem se for somente entradas de dados do usuario… se for um sistema web a view pode assumir esta responsabilidade
[/quote]
Isso se você tem um escopo fixo do seu sistema. Agora e em um escopo indefinido ou indeterminado?
[/quote]
Creio que depende mais da arquitetura do que do escopo… que tipo de escopo vc esta querendo se referir?
Daí desabilitando a permissão de execução de Javascript do browser e te ferram?
[/quote]
Hoje em dia é raro vc conseguir navegar sem javascript… se vc faz isto simplismente nada em ajax funciona… não podera ter nada controlado por javascript… neste ponto dai sim não tem escolha senão delegar isto para o servidor… porem é raro a inexistencia de javascript na web hj em dia… na grande maioria das vezes uma app web sem javascript nem funciona direito… basta vc não deixar o usuario desabilitar o js…
javascript te da muitos benificios…
[quote=townray][quote=luistiagos]É realmente interessante validar no banco tbm… pois alguem fazer inserções na base por fora da app… direto pelo sgdb dai se so validar no client tera uma puta dor de cabeça caso este alguem colocar dados inconsistentes…
[/quote]
Bem, nossas opiniões divergem porém cada um tem direito de expressar a sua. No meu caso eu não quero regras em banco de dados pois pra mim o banco é apenas um lugar para tornar persistente o estado em um determinado tempo do meu sistema, poderia ser um SGBD, um XML, um TXT, etc. Agora inclusões diretas em estruturas ustilizadas pela minha aplicação seria um problema de segurança e não de validação.[/quote]
Depende… se o usuario manda vc dar acesso total a base para ele mesmo fora da app?
o cliente que manda… mas tbm prefiro usar o banco so pra persistir dados…
[quote=luistiagos]
Depende… se o usuario manda vc dar acesso total a base para ele mesmo fora da app?
o cliente que manda… mas tbm prefiro usar o banco so pra persistir dados…[/quote]
AEE. Então agora chegamos em um mesmo denominador… nesse caso “goto 1o. post” e se puder responda novamente imaginando este cenário.
Eu curto a ideia de double-check: garantir na visão e no modelo a validação dos dados.
Eu tenho uma visão diferente sobre a camada Controller: para mim, ela está após as Actions/ManagedBeans e antes da persistência. Vejam bem, pra mim Controller é diferente de Action/ManagedBean. MBean só devem receber os dados da tela, normalizar eles e fazer chamadas a Controller. E Model é quase que inteiramente os dados. Quase, pois ela também possui as validações da regra de negócio de cada objeto. Mas essa é a minha visão do MVC. Ela é bem deturpada, mas sempre me foi bem útil. =)
Banco seria útil ter essas validações, mas, como até hj eu nunca fui o dono do banco nos meus projetos(sempre trabalhei em projeto em que eu nunca pude criar nada na base, ou seja, sem DDL), eu ignoro o fato delas existirem, e pra mim, o que vem do banco é perfeito.
Bom, eu acho interessante validar na view com javascript pra melhoria de performance e depois, no servidor, seguir o estilo de validação que o autor do tópico sugeriu. Validar tipos no controlador e regras de negócio no modelo. Isso depende tb do tipo de aplicação é claro.
Daí desabilitando a permissão de execução de Javascript do browser e te ferram?
[/quote]
Te ferram onde? Queda de performance? Pode ser. Por inserirem dados errôneos? Não vai acontecer, ninguém falou em deixar de validar no lado do servidor, isso é obrigatório.
[quote=luistiagos]pois vc pode fazer estas validações apenas no client sem mandar a requisição para o servidor usando javascript, vbscript… pois assim vc tera um ganho em performace (mesmo que minimo) porem tera um ganho… pois assim só serão enviados para o servidor protocolos ja validados pelo cliente… isto poupa processamento do seu servidor…
[/quote]
Daí desabilitando a permissão de execução de Javascript do browser e te ferram?
[/quote]
Te ferram onde? Queda de performance? Pode ser. Por inserirem dados errôneos? Não vai acontecer, ninguém falou em deixar de validar no lado do servidor, isso é obrigatório.[/quote]
acho que a ideia dele era só validar no client mesmo
lendo só esse post dele, foi isso que ele deu a entender…