Solucionado
As classes controller onde tem a função de receber e direcionar a página como por exemplo ContasController
@RequestMapping("/adicionaConta")
public String adiciona(Conta conta){
ContaDAO dao = new ContaDAO();
dao.adiciona(conta);
return "conta/conta-adicionada";
} ContaDAO dao = new ContaDAO();
dao.adiciona(conta);No caso o miolo do método adiciona, isto não seria da parte modelo, já que é uma regra de negócio a gravação no BD?
Lorran, no modelo MVC, as responsabilidades são definidas da seguinte maneira:
[1] Já entrei em diversas discussões no mundo "real", com argumentos fortes para ambos os lados, há quem defenda que regras de negócio devem ser tratadas diretamente controllers, há quem diga que devem ser tratadas em models. Eu sou da opinião que o melhor lugar para tratar regras de negócio seria nas models, já que ninguém melhor que a própria model para conhecer o seu prórprio domínio de dados e responsabilidades, fazendo com que este código seja reutilizado em todo o projeto.
[2] Pesquise sobre um padrão de projeto chamado generic repository, pode lhe dar uma luz e te ajudar a construir argumentos mais embasados sobre como tratar acesso a dados.
[3] Respondendo sua pergunta, acredito que esteja correto, o tratamento de acesso a dados deve ser apenas invocado através da controller e realizado efetivamente na camada de modelo, seja utilizando DAOs ou o padrão de repositorios (minha experiência é com AspNET MVC, portanto estou tentando lhe dar uma ajuda conceitual).
Ok,
Então isso é invocado pelo controller(o correto), o errado seria o método adiciona ser feito na camada de Controller.
Obrigado Daniel
Seria uma boa prática criar uma outra camada Bussines somente para tratar regras de negócio, ao invés de ficar entre a controller e a model?
Isso depende muito do projeto que irá fazer, agrega um nível complexidade a mais, porém dependendo da sua necessidade, pode agregar qualidade em termos de separação de responsabilidades.
É uma alternativa válida e que já vi ser implementada, um projeto MVC, que adicionamente, além da comunicação no padrão, tinha separas as funcionalidades em classes de negócio (BLLs) e acesso a dados (DALs), sendo essas auxiliares ao modelo na solução. O modelo era funcional, ficava com uma estrutura parecida com essa (meio difícil sem uma imagem, mas vamos tentar):
|<= M <=> BLL <=> DAL
DTO |<= V
|<= CEu honestamente achava um pouco confuso, já que em projetos em N camadas essas mesmas nomenclaturas eram usadas para cada uma das camadas, mas este projeto eu não peguei do zero para entender as razões que levaram a tomada desta decisão de arquitetura.
Que explicação show, muito obrigado Daniel.