Pessoal,
Segui um passo a passo de organização de código MVC (Model View Controller) e resumidamente ficou assim:
…gui = Pacote com classes de interface gráfica
…controller = Pacote com classes que tratam os eventos das classes de interface gráfica
…model = Pacote com classes que fazem acesso ao banco de dados
Alguém pode me dizer se tá certo assim?
Outra coisa, regras de negócio são as classes principais exemplo: Em um sistema de escola seria: Usuario, Materia, Curso… etc com seus atributos e métodos get/set. CERTO OU ERRADO??? Em que pacote do MVC ficam essas classes???
Obrigado!
Vou dizer a minha opinião. Você pode discordar completamente e ainda ter razão.
Veja bem, você está pensando em MVC de forma macro. Quando você diz que o model é o pacote que tem as classes que fazem acesso ao banco, você está separando em camadas e, na minha concepção, MVC não é isso. MVC é uma forma de organizar componentes dentro da mesma camada.
Acho muito mais interessante usar ele em pequenos lugares. Por exemplo: sua view é o Swing (JLabels, JButtons, JTextAreas), o controller contém os eventos e o model representa o bean que está na tela. Veja que não falei em nenhum momento em camada, layer, dao, banco, nada. Esses três componentes podem, muito bem, ficar na mesma classe. Na minha opinião, banco é infra, não tem regra de negócio. E se você for parar pra ver, Swing por si só é MVC.
Claro, nada impede você de colocar o nome dos seus pacotes de modelo, view e controller. Mas não confunda o conceito de MVC com o conceito de camadas. Por exemplo:
- model: Usuário, Matéria, Curso;
- controller: classes que vão delegar pro modelo ou pra infra (por exemplo usuario.isAutorizado(), usuarioDao.salvar(usuario));
- view: visualização em geral;
- infra: a parte mais específica do banco (que lida com drivers ou EntityManagers, por exemplo);
- dao: seus daos.
Em sistemas legados, por exemplo, é interessante mapear a tabela do banco na infra (digamos infra.tabelas) e colocar o modelo em model. Por exemplo, se o nome da tabela no banco é CLIENTE_ALUNO_PROFESSOR (por alguma razão decidiram agrupar tudo numa mesma tabela), você criaria três classes no modelo: Cliente, Aluno e Professor (quem sabe uma superclasse com atributos em comum). As classes ficam mais simples e tudo fica no seu devido lugar.
Então wellingtonfoz.
Estou me formando em sistemas de informação este ano e estes conceitos ainda são novos pra mim.
Ontem fiz justamente uma pergunta como a sua para um professor.
Estamos utilizando JPA pra criar um projeto que compreende à todas as disciplinas da área de desenvolvimento que vimos no curso: fizemos o mini-mundo, modelagem (criação dos diagramas da UML), levantamento de pontos de função, persistência em banco e vamos até a geração de relatório com o iReport.
Perguntei pra ele se, ao utilizar JPA estamos usando o padrão MVC. E a resposta foi sim.
Neste projeto temos os seguintes componentes: classes de entidade (que seriam classes da camada Model), classes do controlador JPA (que seriam classes da camada Controller) e as telas (que seriam as classes da camada View).
As classes de entidade (Model) são as classes principais do negócio, que representam o domínio em questão (Aluno, professor, turma…).
As classes do controlador (Controller) são responsáveis pela persistência propriamente dita, pela destruição de um objeto, edição…
As telas (Views) controlam os eventos de tela (clicks…) e chamam as funções do Model (sets & gets) e do Controller (AlunoJpaController.create(a), p.ex.).
Com relação aos pacotes do projeto, adotei o seguinte padrão:
gui: telas
negocio: classes de entidade
jpa: classes do controlador
Este é o meu ponto de vista sobre o assunto!
PessoALL,
Vale a pena dar uma olhada em
http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
Outras referências:
MVC (padrão para camada de apresentação): Martin Fowler, Padrões de Arquitetura de Aplicações Corporativas
Camadas (exemplo): Eric Evans, Domain-Driven Design