MVC2 e Webwork

As Actions são tua camada de regras de negócio, Model é tua camada de banco, num ambiente MVC2 não tem por que as validações ficarem no Model.

Olá Rafael Nunes,

Não é bem isso que pessoal diz aqui http://www.guj.com.br/posts/list/18940.java

Mas, me confundo um pouco até que ponto devo separar as camadas…

Como assim, feitas na action, cara-palida?

Bem, conforme foi discutido lá, eu não vejo problemas em deixar as validações na Action, quando é uma app simples(me precipitei afirmando em deixar as validações na Action sem especificar as situações), em sistemas mais complexos você cria teu domínio e a partir dele faz as validações e regras de negócio necessárias, creio que num ambiente assim tua Action serviria mais como um Business Delegate.
Só não vejo sentido em deixar validações para a tua camada Model.
É uma opção tua deixar ou não as validações na Action, só basta analisar o que isso pode lhe trazer futuramente.

Posso clarificar umas coisas antes? “MVC2” nao existe. Ou voce esta falando de Model-View-Controller (MVC), ou vc ta falando de Model 2 (que eh um sinonimo de MVC de qqer forma).

Model nao eh “a camada de banco”. O domain model eh onde fica (ou deveria ficar) toda a inteligencia de negocios do seus sistema, e isso provavelmente nao eh soh a persistencia pra justificar de chamar ela de “camada de banco”, a menos que o seu sistema seja muuuuuuuito chato

Olá CV,

Falo de regras de negócio nas actions… isso me preocupa: e se amanhã eu resolvo utilizar outro framework MVC? Fico muito amarrado não fico?

Não tenho muita experiência com MVC2 e gostaria de entender qual a melhor forma de trabalhar.

Devo ter uma Action que chama um Servlet para processar regras de negócio? E a validação de campos (tipo e-mail inválido…) deve ser feita realmente nas actions? Se devo ter esse Servlet, ele deve chamar outra Action (do controller) pra depois direcionar para uma JSP?

É mais ou menos isso que estou com dúvidas…

Um exemplo de arquitetura cairia bem.

Grato.

Caraleo, ou eu sou analfabeto funcional, ou aquele Struts in Action é muito tosco.
De qualquer forma, eu já utilizei o Struts e o Webwork em duas apps.
No Struts como eram operações CRUD e quase não haviam validações e regras de negócio, eu fazia tudo nas Actions. No Webwork eu utilizei as actions apenas como Business Delegates.

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.

jprogrammer:

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.

Qual Livro ???

Era o aprenda J2EE em 21 dias.
Ele não dizia isso explicitamente mas era a ideia que ele passava.
Mas acredito que era apenas para smplificar a abordagem não que os autores estavam errados.
Pois o livro foca J2EE não programação OO.

J2Alex:

Falo de regras de negócio nas actions… isso me preocupa: e se amanhã eu resolvo utilizar outro framework MVC? Fico muito amarrado não fico?

(…)

Um exemplo de arquitetura cairia bem.

No caso do WebWork, vc fica tao pouco amarrado que nao tem tanto problema (afinal, Action eh uma interfacezinha de nada e tal). Se voce for trocar de framework, suas actions provavelmente vao ter que sofrer um refactoring meio fortinho, entao nao adianta muito falar sobre isso: voce vai ter que mexer no codigo das actions de qualquer jeito caso tome uma decisao dessa, assim como voce teria que mexer alguma coisa no codigo do teu modelo caso resolvesse trocar o Hibernate por JDO.

Certo CV,

Mas o que vc me diz: a lógica de negócio fica ou não nas actions? (Acho que já sei a resposta…)

Qual a melhor forma de se dividir as responsabilidades?

Como o cv disse, as regras de negócio ficam no seu domain model (a menos que você não queira usar um domain model, e se for o caso por favor me explique sua idéia porque estou querendo saber mais sobre isso). Suas actions são fluxos customizados, numa aplicação pequena elas podem servir como camada de aplicação, que diz aos objetos de negócio o que elas querem (não como fazer).

Não coloque regra de negócio em actions a menos que você estja conscientemente produzindo um sistema altamente procedural e acoplado. Eu sei, vivo isso e sei a mer&$&% que é tentar reutilizar lógica neste ambiente.

Olá pcalcado,

É justamente o que eu estou pensando: a melhor maneira de reduzir as dependências, o acoplamento.

Como eu disse, não tenho tanta experiência com MVC (eu desenvolvia em ASP :shock: ) e estou buscando a melhor maneira de desenvolver software de fácil manutenção.

Pra camada view eu decidi usar o freemarker, até aí tudo bem. agora estou estudando Webwork, blz, entendi perfeitamente o seu funcionamento, so fiquei em dúvida com relação ao papel do controller e do model.

Pretendo usar Spring pra camada de negócios, mas ainda não comecei a estudar. Mas já estou divagando antecipadamente. Qualquer dica é bem vinda.

Grato.

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”?

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

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:

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

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

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

public void efetuaVenda() {
   // efetua a venda.. 
   
   // cria a nota fiscal! Isso pra mim é criar uma nota fiscal no modelo!
   NotaFisca nota = new NotaFiscal();
   nota.setVenda(venda);

   // agora vou persistir...
   Dao dao = new VendaDao();
   Dao dao2 = new NotaFiscalDao();

   dao.save(venda);
   dao2.save(nota);
}

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…