MVC2 e Webwork

para sua camada de negócios, use Java.

Para controle de dependências, ciclo de vida...Spring pdoe ser uma boa

IMHO, os framewoks mvc, não fazem o papel das tres camadas, não é a função deles.
Eu acho que eles são o "V" do padrão, eles são a view, como se a view fosse subdivida. Por isso eles não podem ter regras de negocio, eles devem delegar essa responsabilidade para camada responsavel por isso.
Dessa maneira fica mais facil de manter o sistema.

[]'s

jbgt, pq vc acha que frameworks como o WebWork nao sao tambem o "C"?

cv wrote:jbgt, pq vc acha que frameworks como o WebWork nao sao tambem o "C"?

Tu vai no detalhe tmb ne?
Com certeza eles tmb são o "C", pq eles possuem um "ServletController", ou coisa parecida.
So quis dizer que eles devem se limitar a ser a visão da app, sem regras de negocio.
Muita gente acha que MVC é jsp/VM/uix.. etc com o V, o "ServletController" como C e as actions como o M..
P/ mim eles estão dentro de uma unica camada.
Melhorou??

[]'s

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Olá J2Alex!

Vc quer mesmo usar tudo isso de framework? A aplicação é tão grande assim ou é para aprender !!!???

A diferença entre modelo e controle são as seguintes:

Modelo --> São todos seus objetos de negócio, como por essemplos, as classes que representam a abstração do problema, relacionamentos e operações que cada objeto é capaz de operar. Eu entendo camada de modelo como se fosse isso! Vc deve garantir que um objeto aluno possui apenas valores validos, e que ele possa trocar de turma, e que quando vc executasse o método trocar turma do aluno, o relacionamento deve ser atualizado.
Quando estou desenvolvendo meu modelo, eu descarto do modelo os métodos CRUD (create, update e delete). Isso para mim não faz parte de modelo, e sim persistência!

Controle --> Controle é responsável por executar uma operação solicitada pelo cliente! Ele recebe os dados da camada de visualização, cria os objetos de negócio, diz ao métodos de negócio o que se deve fazer e depois persiste o estado dos objetos no banco de dados! Ou seja, entenda que o objetivo do controle é executar a operação solicitado pelo usuário, como por exemplo, enviar email, cria conta, salvar alterações e etc...

jprogrammer wrote:Esse livros são porigosos mesmo.
Estava lendo uma livro de EJB e ele dizia para colocar as regras de negócio nas Sessions Beans.

Viu... não sei não viu! Dependendo da arquitetura, acho isso válido! Prefiro não fazer isso, é claro. Mas veja bém, entre colocar a lógica de negócio em um EntityBean ou um Session, sou mais colocar a lógica no Session Bean. Uma idéia que me atrai é vc limitar as operações que podem ser efetuada na sua camada de negócios usando um façade. Essa idéia miha nunca coloquei em prática ainda, mas ainda considere que criar seu modelo usando POJOS seja mais elegante!

Abraços!
Thiago

Thiago Senna wrote:Quando estou desenvolvendo meu modelo, eu descarto do modelo os métodos CRUD (create, update e delete). Isso para mim não faz parte de modelo, e sim persistência!

Pq "criar uma nova nota fiscal quando uma venda eh efetuada" nao faria parte do seu modelo de negocios, e sim da persistencia?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

cv wrote:

Thiago Senna wrote:Quando estou desenvolvendo meu modelo, eu descarto do modelo os métodos CRUD (create, update e delete). Isso para mim não faz parte de modelo, e sim persistência!

Pq "criar uma nova nota fiscal quando uma venda eh efetuada" nao faria parte do seu modelo de negocios, e sim da persistencia?

Concluindo:

Para miim, o que importa é criar um objeto conta e a nota! Nada mais que isso.
Depois eu persisto o estado dele para que possa ser recuperado em uma outra oportunidade....

Notícias, artigos e o maior fórum brasileiro sobre Java