Framework MVC não pode atrapalhar?

Sem entrar tanto no merito da questao se eh melhor ou nao, voce nao eh obrigado a extender ActionSupport - basta apenas implementar Action.

http://www.opensymphony.com/webwork_old/fundamentals-action.html
http://www.opensymphony.com/webwork_old/api/webwork/action/Action.html

Marcio Kuchma

Nossa… esse assunto tá um bom caldo!

Olha a bagunça que eu apronvei aqui uma vez:
http://www.guj.com.br/posts/list/21002.java
http://www.guj.com.br/posts/list/21007.java
http://www.guj.com.br/posts/list/21017.java

É uma salada, mas ainda ha posts melhores!

Até onde sei, mesmo que vcoê opte por criar um fronte controller, você ainda teria que adotar alguma estratégia mais ou menos do tipo Command and Controller. OU seja, o front controler recebe a requisição e encaminharia ela para o command responsável por executar a tarefa. O command nada mais é do que um Action. Sendo assim, essa é uma estratégia normal. Não é gerado mais trabalho braçal se comparado com o uso do webwork ou struts.

O Action também não deve conter lógica de negócio. Ele apenas fará alguns logs, inicia uma tranzação, cria os daos e persiste e blábláblá. Lógica de negócio devem ficar nos POJO’s.

Quanto ao DTO, se não é uma aplicação distribuída, e roda tudo na mesma jvm, estão esquece essa gambiarra… ou GOO. Gambiarra orientada a objeto, como diz nosso amigo Skill!

Isso porque os Pojos já podem fazer direto o papel do DTO. Ou seja, DTO ai se tornaria uma espécie de redundância!

Abraços!
Thiago Senna

[pseudo-quote]
No começo era o protocolo http, e tudo era frio e sombrio. Então Ele disse, que haja Servlet. E formaram-se as classes wrappers e o Servlet. E viu que isso era bom… Mas faltava uma forma mais fácil de criar páginas dinâmicas. Então Ele disse: que haja o JSP. E tudo isso era bom …
from Boof of Indonesia´s islands
[/pseudo-quote]
Mas você ainda teria que trabalhar com o HttpRequest na mão. E fazer o mapeamento entre as ações das páginas e as chamadas de métodos apropriados para cada ação (tosco!).

O Webwork, os demais frameworks web, vieram para dar uma mão na parte de CONTROLLER mesmo. As classes de negócio devem continuar nos objetos de negócio. Mas não vão mais precisar tratar coisas como httprequest. Ficou separado…

usuário --> protocolo http -> classe httpRequest -> Action -> classe de negócio

Nota: num mundo ideal… você não teria essas camadas:
usuário --> classe de negócio

De fato DTO foram criados para resolver o problema de camadas de serviços. Não que seja bom para a orientação a objetos, mas é uma solução para um problema técnico.

Mas uma vez, no mundo ideal, não haveria esta barreira.

Entonces, esse erro é comum em pensar que a Action vai ser seu modelo de negócios (eu fiz isso :oops: )… não vai!

Em sistemas pequenos não há muito problema com isso, já que apesar dessa herança (na verdade vc não é obrigado, extende só porque a ActionSupport te dá suporte a um monte de coisa) você vai pode reutilizar a Action porque ela não está ligada ao ambiente web (ela trabalha apenas com um monte de maps).

De qualquer modo não é uma boa idéia fazer a Action o seu Front Controller porque essa é justamente a função e a facilidade que o webwork te dá (com o servlet que controla as requisições trabalhando os contextos, results & cia) …
A action está mais para atuar como um Business Delegate que então conversa com suas classes de negócio (ou continua a arvorizinha de patterns se seu problema for sério) …
(posso estar me perdendo nos patterns, alguém comenta?)

Quanto ao DTO … lembre-se que eles são pra TRANSFERENCIA, se você usá-los só pra isso sem problemas

DTOs são uma otimização e por isso aumentam o custo de desenvolvimento e manutenção, se mandar um monte de objetos não for comprometer a performance, escrever DTOs é perda de tempo.

Cara, só pelo fato do webwork popular os beans perfeitamente, fazendo conversões e populando coleções, já compensa usar, pois teria que fazer isto manualmente.

Frameworks MVC atrapalham quando você não tem nem uma dúzia de páginas que só fazem CRUD. Fora isso, se está te atrapalhando, ou você não escolheu o framework certo ou não estendeu de forma adequada.

Pelo que percebo os frameworks web são muito bons para portais e web-pages.
Pois esses tipos de sistemas se baseam em telas e uma navegação não padrozinada, ou seja, cad tela que uma funcionalidade distinta.

Para sistemas ERPs, onde as telas seguem um padrão de design e funcionalidades padronizados o que se tem é um serviço muito braçal.

Nesses tipos de sistemas o modelo de dados e negócios se integra na interface.
ex:

• campos de pesquisa com relacionamentos para outras entidades.
• campos de uma mesma entidade espalhados por várias telas de sistema.
• muitas telas estilo CRUD.
• campos foreign keys nas telas
• se eu mudo o tamanho de um campo tenho que mudar manualmente em cada tela.
• validação de campos baseados no modelo de dados e negócios de forma automatica.

Fica muita braçal implementar esses tipos de funcionalidades em um struts, web-work, etc.

Gostaria de saber se há algum outro tipo de ferramente sem que seja gerador de código para facilitar isso.
Nunca me deram a resposta…

Pelo pouco que conheço de frameworks MVC, Template Engineers, blablablablablabla, ter design e funcionalidades padronizadas são o q te ajudam a ter um trabalho menos braçal do que o normal…

Desde que seu modelo de domínio esteja bem formulado, não vejo problemas em utilizar entidades X ou Y, ou as duas juntas em diversas interfaces de usuário em seu sistema.

Não tem absolutamente nada a ver esse trabalho braçal que você citou com o uso ou não uso de frameworks mvc. É um problema relacionado ao ambiente web, que pode ser muito amenizado pelo uso de templates.

Sobre geração de código, dê uma olhada no EclipseWork.

Usar entidades juntas não é o problema mas a necessidade no caso.
O problema é que os frameworks MVC que temos não ajuda nesses casos
tenho uma tela que tem uma campo de uma entidade que se relaciona com um campo de outra entidade.

por ex:
um cadastro de funcionario
tenho um campo codigo do departamento nesta tela.
preciso clicar em botão de pesquisa, depois da tela de pesquisa ser aberta , faço a pesquisa do departamento clico no registro que quero e o campo é preenchido.

essa tarefa é muito ardua pelo menos no struts.
quanto html e código eu tenho que fazer para fazer esta tarefa simples.

dei uma olhada no E-GEN.
é sensacional, gera o código do struts automaticamente.

Mas fora gerador de código tem algum framework que faz data-binding e faz uso de templates ou outra coisa que agilise o desenvolvimento ?

jprogrammer, não tem mesmo.
Mas nada que uma semana de desenvolvimento não gere uns componentes reusaveis necessarios.

Lembro de ter escrito uma action pro webwork que populava dinamicamente combos usando Ajax em pouco mais de um dia, testando com IE e FireFox. O projeto tinha muito daqueles caso de combos em cascata, pais-> estado -> cidade, por exemplo.

Como o LIPE falou, este problema eh estritamente relacionado com o ambiente ao qual vc estah desenvolvendo…

Tentou fazer a mesma coisa sem os frameworks MVC?
Terá no mínimo o mesmo trabalho!

Não usar os frameworks talvez não seria a solução.
Mas talvez extende-los como já foi discutido aqui e como o louds disse.

Criar componentes reutilizaveis e uma arquitura inteligente pode gastar um pouco de tempo que podemos poupar lá na frente.
Vale apena sim, é um desenvolvimento inteligente.
Mas algo pronto. Porque ninguém pensou em criar alguma coisa assim.

O problema desses frameworks MVC é que são generalistas demais.
Podem ser usados para fazer desde de um chat até uma aplicação corporativa.

Se fazem um framework muito especifico, nego reclama e diz que nao serve pra nada pq nao da pra fazer o que a aplicacao dele precisa.

Se fazem um framework generico, que resolve a vida em 95% dos casos e facilita os outros 5%, nego reclama pq o caso especifico dele nao tah na parte que ja veio pronta.

Haja. Saco.

Não vejo isso como um problema. Por que você considera assim?

Se você precisa de databinding em “tempo real” na sua aplicação web:
a. mude de ambiente
b. use JSF, e sofra as consequências
c. use AJAX, e sofra as consequências

Eu não disse q seria…disse q vc terá um trabalho maior se não usá-los, embora não resolvam todos os problemas da querida pátria Ucrâniana!

Não é problema, é a característica que permite a adoção A parte específica é ligada as definições de interface gráfica, negócio da aplicação etc. e por isso mesmo deve ser feita para a empresa como um todo, um departamento, um projeto ou parte dele, e não para pessoas do mundo todo usarem. Se você analisar de outra forma, esses frameworks são específicos o suficiente para seu público alvo: desenvolvedores Java web.

Ainda bem, né? Caso contrário não seriam frameworks

Porque o JSF não está pegando ?
Pelo que vi é muito interessante.
Parece muito com o ASP.NET.

Seria o caminho para uma padronização do desenvolvimento web.
O que falta é uma framework event-driven com componentes GUI reais.
Não essas actions e fowards.
O java tem uma estrutura muito melhor que o .NET para construir isso.

Pelo que ouvi falar até a Apache prentende abandonar o Struts para se dedicar ao JSF.

O que seria esse Ajax ?

jprogrammer:

O que falta é uma framework event-driven com componentes GUI reais.
Não essas actions e fowards.

Sim, não fata um framework de actions e forwards exatamente porque eles já existem. Porém e antes de existirem?
A não existência de um, não invalida a existência do outro.

Não desconsiderando esse sistema de fowards e actions.
O ponto que quero colocar é que é mais fácil você construir uma interface baseado em componentes GUI reais que tem estado, interagem entre si, são orientados a objetos, se baseam em eventos do usuário e saõ extensíveis do que as actions e fowards.

Eu conheci recentemente o struts layout. Achei bem interessante.
Mas gostei mais do JSF.

Por que ainda não está pegando ?
Alguém sabe se alguem já está utilizado ele em algum projeto profissional ?

Se delicie:
http://del.icio.us/tag/ajax

JSF esta indo bem, mas lembre-se de que nao eh soh JSF que existe nesse nicho. Veja tambem Tapestry, Echo, e amigos.

Sobre Ajax, STFG.