Alguem sabe se validação de campos fica na camada de interface ou regras de negócio?
Porque pode ser na interface, pois é apenas “jeito” de exibir os dados na tela para o usuario;
ou pode ser regras do negocio pois algum tipo de validacao depende das regras da empresa, por exemplo, um campo se é obrigatorio ou nao. Para uma empresa ele pode ser obrigatótio e para outra pode não ser.
Então gostaria de saber onde é mais adequado eu por minhas validacoes de campos, regras de negocio ou interface…
Ambas as camadas, mas em geral, as validações na view são mais contra erros primários, tipo erro de digitação, caracteres não permitidos etc. Na model, as validações são mais inerentes a regra do negócio, tipo um cliente tentando se cadastrar 2 vezes. Depende do seu conceito de regra de negócio e requisitos básicos, mais isso não deixa de ser algo “pessoal”.
Vc pode fazer com que esteja em ambas as camadas, inclusive exportando certas validações entre uma camada e outra.
O melhor exemplo seria um campo ‘email’ que é validade através de uma expressão regular: vc pode exportar essa ER para a view e assim deixar o campo verdinho/vermelhinho sem necessidade de fazer nenhum request ajax, por exemplo.
Porém vc pode continuar verificando nas camadas mais ‘internas’, afinal se a view deixar passar alguma coisa por algum motivo (ex: algum javascript defeituoso ou algum browser maluco, etc) vc não vai ter dados estranhos no seu banco de dados.
Oui. Geralmente, as validações e seus intuitos são diferentes para cada camada, então é complicado unificar em um lugar só essa questão.
[quote=ad_icm]
Uma outra coisa…
as camadas sao “Interface”, “Regras de Negocio” e “Integridade”, vou vcs dao outros nomes?[/quote]
Eu sou um dos chatos que acha que não se deve traduzir nomes de conceitos e/ou tecnologia (pode gerar algumas coisas muito ruins). MVC é Model/View/Controller, aportuguesar esse tipo de coisa nãoi fica bem e gera conflito de interpretação.
View - Telinha do usuario Controller - Recebe o que vem do View ou model, se tiver regras manda para model Model - Uma porção de regras, verifica se pode isso, verifica se faz akilo…
O controller pode ter uns bagulhos para verificar se pode ou não passar adiante tipo, enviar para uma regra da model apenas se tiver todos os campos do furmulario preenchido
Cada objeto é responsável por sua própria consistência!
É muito comum validar apenas a view, supondo que as demais camadas não receberão entradas inesperadas, pois as coisas estão vindo corretas lá de cima. O problema é que view é sempre o principal alvo de alterações e qualquer deslize ferra tudo que está embaixo.
[quote=bobmoe]…
Cada objeto é responsável por sua própria consistência!
É muito comum validar apenas a view, supondo que as demais camadas não receberão entradas inesperadas, pois as coisas estão vindo corretas lá de cima. O problema é que view é sempre o principal alvo de alterações e qualquer deslize ferra tudo que está embaixo.[/quote]
Eu acho uma péssima prática deixar que a view controle toda a validação. Certas validações são inerentes ao model ( como duplicação de dados, não-coerência dos dados etc ), e mesmo que tenha uma validação na view, pode-se escapar algo previsto ou não, então é mais seguro que os dados verificados na view também o sejam na model ( que nunca ouviu falar em SQL injection? Se for depender só da view, estamos danados).
Mas como tudo, tenha parcimônia no que faz. Faça que algumas validações desnecessárias não sejam realizadas em locais errados ( verificar na view se cliente existe carregando meio banco de dados para um javascript ).