Pessoal, estou com uma dúvida sobre MVC. O meu projeto é dividido entre model (onde fica os javabeans), modelBLL(onde fica as regras de negócio), modelDAO (onde fica as classes de persistência), controller e view, minha dúvida é a seguinte: onde eu devo chamar os métodos das classes de regra de negócio, no controller ou no modelDAO?
OBS: nas regas de negócio eu tenho basicamente só validações.
Cara, que salada, hein?
Existem N pontos de vista sobre a organização dos vários patterns dentro do pattern MVC (sim, DAO é um pattern à parte).
Eu fico com a opinião do sp00m nesta thread. Dá uma olhada.
se a sua validação é desconexa do modelo, então vc poderia fazer isso no modeloDAO.
no controller eu acho esquisito a menos que vc queira fazer algo que não seja relacionado ao modelo ( sei la, detecção de fraude? )
na view vc pode ter algumas regras, aqui entra a questão de usabilidade e performance. mas não pode ser só na view se for um projeto web IMHO.
validações na view em geral vc tem javascript e html que podem ter o comportamento alterado pelo browser.
Acho que validações na DAO devem ser, única e exclusivamente, relacionadas a interação com o banco de dados.
Eu prefiro colocar as validações em uma camada intermediária de controle, a service, como o artigo sugere. Penso que é mais limpo e menos intrusivo.
Depende das regras e da estratégia do banco de dados.
Tem banco sem integridade referencial onde vc vai ter q checar mais coisas que o normal (e pode ser papel do DAO)
Tem regras que vc pode codificar como restringir opções usando Enumerações e outros tipos de dados. Outras regras (um aluno não pode estar matriculado em disciplinas q tenham colisão exceto com liberação X de Y) merecem um layer só pra isso
Eu acho
E não é, exatamente, o que eu disse?
Se a gente vai seguir essa abordagem, entendo que não se precisa dividir responsabilidades. É um princípio básico da orientação a objetos e, este, é um pattern a ser utilizado e considerado antes de qualquer outro: tudo o que não está diretamente ligado as razões pelas quais uma classe existe, deve estar em outra classe.
A função do controller é só fazer o meio de campo entre a view e o model, que inclui o DAO. A função do DAO é, apenas, interagir com a base de dados. Logo, o MVC “tradicional” (que só funciona para CRUD básico) é falho. Devido a isso é que se justifica a criação de uma camada intermediária (ou mais camadas intermediárias, de acordo com os patterns “pendurados”, como o DTO, por exemplo).
Onde você colocaria as regras de negócio, por exemplo, a manipulação de valores salvos no banco de dados e que devem ser exibidos em um relatório sintético?
Eu entendo que tu deveria chamar na camada de controller, da mesma forma que o Darlan falou, a camada DAO deve ser apenas para comunicação com o banco. Quando tu chega nela (DAO), é sinal que as validações necessários já foram feitas. Cada camada com a sua função.
Pelo menos esse é o meu entendimento.
E não podemos confundir validações javascript com regras de negócio. Na view, usar o javascript apenas para tratar a entrada dos dados (exemplo, verificar CPF valido), vendo a quantidade de caracteres e etc. Para quando chegar na camada DAO, aquele dado esteja correto para inserir em banco.
Obrigado pessoal pelas respostas. Eu esqueci de falar que o projeto é desktop. Então, minhas regras são basicamente validações como por exemplo verificar se algum dado obrigatório foi informado pelo usuário, validar cpf, cnpj etc, então vocês acham que eu devo chamar esse métodos de validação na view ou no controller?
Desktop Java se conectando direto com o banco?
Sim, banco local.
Independente de validações e n siglas, seu banco está totalmente vulnerável no client se descompilarem. Em relação a MVC, deve chamar a validacao dentro do model, é quem deve “garantir” a integridade dos dados seguindo MVC. Pode chamar as validações através de uma classe de serviço como @darlan_machado falou. Como ele falou também, Controller só faz o meio de campo, não é responsável por decidir validar.
Desta forma seu model pode ser reutilizado garantido que os dados serão validados.
Como está usando Java, creio que o recurso mais indicado seja o bean validation, mas conheço pouco pra afirmar.