tenho muitas duvidas com relaçao a integraçao da logica de negocios na camada de modelo. (Considerando o MVC).
exemplo: tenho uma classe matricula. Essa classe possui uma tabela no banco de dados, para que possa ser populada utilizando o hibernate, mas, ao mesmo tempo essa classe tbm possui logica d negocios e tbm requisitos do sistema (verificarDisponibilidadeCurso(), enviarMensagemAluno()).
como isso seria implementado? duas classes? classe Matricula e classe MatriculaLogicaNegocios ou uma unica classe unica que preserve as caracteristicas da orientaçao a objetos (pojo + logica de negocios)?
tenho muitas duvidas com relaçao a integraçao da logica de negocios na camada de modelo. (Considerando o MVC).
exemplo: tenho uma classe matricula. Essa classe possui uma tabela no banco de dados, para que possa ser populada utilizando o hibernate, mas, ao mesmo tempo essa classe tbm possui logica d negocios e tbm requisitos do sistema (verificarDisponibilidadeCurso(), enviarMensagemAluno()).
como isso seria implementado? duas classes? classe Matricula e classe MatriculaLogicaNegocios ou uma unica classe unica que preserve as caracteristicas da orientaçao a objetos (pojo + logica de negocios)?
a idéia e essa…poderiam me ajudar?[/quote]
A classe Matricula verifica a disponibilidade do curso ? Não deveria ser o Curso a verificar isso ?
Curso c = ...
c.isAvailable();
Tlv em primeiro lugar vc precise de um modelo mais completo e não embutir tudo num lugar só
Vc “deve” ter apenas uma classe, mas isso não é uma regra. Deveria ter só uma porque é mais simples de manter. A persistencia deve ser feita por classes especiais para isso. Essas classes recebem seus objetos de negocio e os persistem. tipo assim
Matricula m = Matricula.novaMatricula(aluno,curso); // matricula o aluno no curso
Persistidor p = new Persistidor ();
p.persiste(m);
Em um padrão MVC, não há dificuldade nenhuma em dizer qual parte é a view, normalmente é o HTML, o JSP, ou a estrutura de componentes visuais em Java. O problema surge na hora de se separar o model do controller: já ouvi gente dizer que o controller são as regras de negócio, e o model são os dados ou os POJO. Não é nada disso. Qualquer coisa que faz sua aplicação funcionar, tanto as regras de negócio quanto os dados, pertence ao model. O controler é apenas aquela parte do código que irá responder a alguma interação do usuário e nada mais. E o model ainda pode ser dividido em camadas também, como os tão badalados DAOs, mas estes ainda não deixam de ser model.
Paulo Siveira, você respondeu minha pergunta de forma abstrata! tem como passar alguns detalhes? Os links q vc me passou não tratam do assunto sobre a divisão das responsabilidades de forma clara…
O hibernate poderá encontar algum problema em popular os atributos de um objeto que não seja um pojo e sim de uma classe de negocios que contenha herança e tudo mais?
Um POJO, um DAO e uma classe de negocios são coisas totalmente independentes, porem todas estão na camada model certo?
São sim: POJOs: Classes java que não possuem dependência de nenhuma tecnologia específica, neste caso a tecnologia citada eram os EJB do tipo EntityBeans, mas não restritivo a eles.
Quanto a relação entre o DAO e os POJOs. A idéia é imaginar o DAO como uma “entidade fraca” em relação a Entidade que ela provê serviços de persistencia.
E sim, ambas implementam conceitos da camada Model do modelo MVC.
pelo que pesquisei, existem duas formas : uma que aprecia mais a OO e a outra que aprecia menos.
seguindo a risca a OO, entao uma classe tem tanto estado quanto comportamento, fator que leva crer que uma classe não é uma tabela e que ela deve ter seus comportamentos
por outro lado, existem as formas de desacoplar isso criando uma entidade POJO e colocando a logica em outros lugares (isso vai depender do tamanho da aplicaçao e de outros fatores)
agora a pergunta é: O hibernate sabe lidar com isso (ex: herança)? ou serei obrigado a construir pojos?
Zakim, um pojo nao é um objeto que nao possui logica de negocios. Muito pelo contrario, um bom-e-velho objeto java contem sim logica de negocio. E nao é so porque voce colocou logica de negocios na entidade que voce nao vai reaproveitar aquela logica nao…
O hibernate nao tem problema algum em trabalhar com classes que possuam metodos de negocio. Mas tome cuidado com a henrança :
: