Vamos supor:
Existe uma classe Usuario que faz parte do meu modelo de domínio e esta classe tem um método cadastrar.
Para eu acionar o métido cadastrar é necessário que o objeto tenha um mínimo de atributos preenchidos.
Eis a dúvida, eu faço está validação no controller? na view? no modelo?
Eis a polêmica. A minha conclusão é que o método cadastrar antes de inserir num banco de dados verificasse a integridade da classe e se está não estivesse integra gerasse uma exceção e o controller e visualização apresentassem o erro.
Porém, a controvérsias, alguns dizem que é melhor tratar esses dados no controller ou na view.
Como vc disse, alguns dos programadores preferem tratar no controller e outros na view…
eu sou do tipo que trata na view, pois dexo a controller responsável somente por mapear as ações…
E considero mais fácil o tratamento na view, ao meu ver o software fica mais “organizado”… (cada camada com a suas responsabilidades…)
fazendo isso, vc encontrará mais facilidade em posteriores manutenções…
Eu prefiro fazer a verificação e lançar a exceção no modelo, mas subir ela pra outra camada tratar.
Imagine que vc tem a classe Pessoa e sua idade nao pode ser menor que zero.
Se você implementa essa validação no controle, utilizando struts por exemplo, e então resolve mudar pra jsf, ou então fazer uma interface swing que utilize o mesmo modelo. Você terá que lembrar dessa verificação e implementar ela novamente.
Deixando no modelo, a exceção sobe e a sua camada de controle terá apenas que tratar.
Trate em todos os níveis envolvidos, assim aumenta a chance de a validação pegar todos os casos.
Quanto mais cedo a validação foir feita, melhor para o usuário “bem comportado”.
No caso de uma aplicação Web, temos várias linhas de defesa: lógica de validação em JavaScript na própria página, lógica de validação no nível do controller, lógica na camada de serviço, no framework de persistência e, por fim, na própria base de dados.
Eu prefiro uma validação no modelo, pois pra mim, só ele sabe quais são os dados corretos. Por exemplo, e se eu reaproveitar meus modelos em outro projeto que não use nenhum framework por exemplo? Utilizando em um software para Desktop, ou para um em console. Teria que replicar toda minha validação? Ou utilizar frameworks de validação ou criar meu próprio? Carregaria uma tonelada de Jars pra todo lado? Em meus projetos eu tenho esse problema, por isso a preferência.
Eu reforço minha idéia, ao ver os servidores de bancos de dados, a grosso modo, as restrições são embutidas nas tabelas, o próprio SGDB cuida dos dados e de sua integridade, só ele sabe como as coisas funcionam.
Mas isto varia de projeto para projeto, veja as opniões e avalie seu caso, em projetos 100% Web pode ser que uma validação no modelo não seja adequada, pois você teria que percorrer um caminho “muito longo” pra responder ao usuário algum erro que ocorreu lá na última camada, por exemplo.
A questão é aonde ESTÁ a regra. Se a regra é da entidade ela deve estar na entidade. Se ela é do processo ela deve estar fora da entidade.
Os Frameworks atuais ajudam. Dá uma olhada no Validator do Hibernate. Jboss Seam + Validator é muito bom. Algumas regras com relação à entidade podem ser tratadas numa operação anotada com @PrePersist num ambiente JPA.
A responsabilidade é de quem for resolver o problema.
Se sua view não vai resolver ou contornar o problema, não existe a necessidade dela capturar e “tratar”(leia-se ignorar).
Voltando a sua dúvida, em seu caso a melhor abordagem é o usuário tratar o erro e devolver ele “mastigado” para a view, sendo assim, ela só precisa formatar de uma maneira agradável para o usuário.
Com isso você pode mudar sua camada de apresentação e até mesmo transformar seus métodos em serviços.