Buenas,
Vejo que recomendam(e eu também sou a favor tanto que uso em toda aplicação web), porém surgiu-me uma dúvida.
No caso do webwork que eu decidi usar aqui num novo projeto, ele me obriga a ter uma classe Action que extenda ActionSuport e tenha o método execute.
Logo, não vou poder usar esta Action como meu objeto de negócio.
Não estaria então gerando um trabalho braçal a mais e desnecessário?)Criar a action, mapear no xml, etc.)
O que eu pensei, já que não tem jeito de não utilizá-la, é transformá-la num front-controller, onde ela só processaria as requisições e encaminharia para os recursos de acordo com a requisição.(Ao menos foi a melhor forma que vi de utilizá-la).
Outra dúvida é quanto ao uso de DTO. Como a maioria das aplicações que faço é em ambiente distribuído, não vejo forma melhor de retornar meus dados. Por exemplo numa requisição não vejo sentido em retornar uma tonelada de objetos para utilizar somente um atributo de cada, a meu ver é mais coerente eu criar um DTO com as informações que necessito e retorná-lo. Mas posso estar errado…
Críticas?Sugestões?Opiniões?Interessa carne de javali?
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!
[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.
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.
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
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.
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.