O MockStrutsTestCase é um Mock para Struts 1.x que não se baseia em POJOs já que suas Actions têm que estender classes do framework. O Struts 2/WebWork acabou com este grande problema adotando POJOs para as Actions, que é algo bem comum em frameworks web como VRaptor, Spring MVC e todos os outros 3423524 projetos open-source.
Não sei há quanto tempo o framework criado pelo órgão público existe, se existir desde 2002-2003 realmente a cultura da época não previa frameworks com POJOs mas há uns bons 4 anos que isso é padrão. A necessidade de um framework para testes do framework é um dos problemas em adotar uma estratégia que obriga classes da aplicação a estender ou implementar classes e interfaces do framework. Sugiro que os autores do mesmo dêem uma olhada no que o mercado vêm fazendo e o porque do uso de POJOs onde existe regra de negócio/aplicação ter se tornado matéria quase que obrigatória para frameworks de todos os níveis.
O engraçado é que quando se trata de qualquer coisa Java, o termo usado é ‘engessado’ e todo mundo odeia, enquanto que quando se fala sobre Rails, o termo usado é ‘opinionated’ e todo mundo adora.
Então acho que o problema é o conceito de testes unitários. testes unitários não podem depender de um container para funcionar, do contrário eles não são unitários mas sim de integração.
Para ser um teste unitário eu devo poder instanciar a action (ou seu equivalente), chamar seus métodos e verificar o comportamento esperado sem depender de containers. Se as classes não podem ser testadas desta maneira simples não é um POJO já que depende da infra-estrutura. Como citei o Struts 1 era assim mas há muito tempo que os frameworks web não possuem mais essas limitações exatamente porque o modelo de programar em Java EE evoluiu visando maior qualidade e flexibilidade.
Para persistência outra técnica utilizada é a divisão em Camadas. Se você divide seu sistema em Camadas ele vai isolar as classes que de fato dependem do banco de dados e você consegue criar mocks para estas classes tranquilamente.
Calma, calma, não é nada pessoal. Na verdade, nem sequer é específico a este framework em questão.
É que às vezes eu acho engraçado que as pessoas dão piti quando se fala em estabelecer uma arquitetura ‘default’ para um determinado framework Java (nome de pacote padrao pra classes de visão, controllers e entidades, tem que ter tal anotação ou implementar tal interface, tem que seguir determinada convenção de nomeclatura, etc.), mas quando se trata do Rails (que possui diretórios padrão pra views, controllers e entidades, vc tem que estender determinadas classes, tem que seguir determinada convenção de nomeclatura, etc.), todo mundo acha lindo, dizem que isso vai destruir o Java, blábláblá.
De novo, não estou dizendo que esse Atena é um equivalente ao Rails pra Java (longe disso!), somente um comentário (genérico) sobre algo que eu tenho observado por aí.
Rails possui uma arquitetura padrão a ser utilizada para projetos com algumas características específicas. Se você não está no cenário adequado ou você usa plugins, ou muda o framework ou usa uma coisa mais apropriada.
uma coisa é definir um framework/arquitetura que é muito boa utilizada num cenário X ou Y, outra coisa é definir uma arquitetura para ser utilizada em todos os projetos, não importa do que se trata. Se um MPU ou alguma empresa adotar Rails como arquitetura de referência vai ser criticado da mesma forma: arquiteturas de referência, caseiras ou não, são o extremo oposto de boas arquiteturas.
O primeiro critério é que o cenário seja analisado e uma arquitetura escolhida a partir dele, não a existência de uma arquitetura genérica. Pode ser a mesma arquitetura utilizada em outros projetos sem nenhuma mudança mas cada situação deve ser analisada.
O segundo critério é observar o que já foi criado pela indústria em termos de software, de prática e teoria e não reinventar a roda ou, caso seja necessário reinventar, que se faça seguindo princípios de qualidade da indústria.
O terceiro e tão importante quanto é que a arquitetura deve ser testável e executável.
Poderia responder que se baseia entre a qualidade de uma decisão tomada por um ser humano ao invés da escolha automática de uma máquina. Mas não vou fazê-lo.
Responderei de outro modo: não existe arquitetura boa ou ruim porque ninguém compra arquitetura. O cliente compra sistemas e este sim é baseado em alguma arquitetura. Se o sistema funcionar bem dentro dos requisitos então dane-se o que tem por dentro.
Mas em contrapartida, quando o desenvolvedor inicia o desenvolvimento do sistema, se lhe é imposto que ele pode escolher todas as cores desde que seja preto, pode ser que se esteja ganhando muito tempo abreviando a escolha mas o resultado final também pode ser prejudicado.
Entenda que NÃO estou criticando seu framework que nem conheço. Sei que muitos daqui não se interessarão por ele enquanto não tiver testes unitários mas isto não quer dizer que ele seja ruim, apenas que ainda não é confiável.
O que eu criticarei é se ele for engessado tal como já expliquei antes. Se está bom para vocês, façam bom proveito mas não queiram que eu seja igual ao prefeito daquela cidade da Virgínia.
Não entendi muito bem, pois há 3 interfaces diferentes com vários métodos.
Dá para usar a validação como filtro/interceptor ou só atrelando ela a Action?
Como eu construo minha propria regra de validação, por exemplo para validar se o campo segue a regex ^[A-Z]+\d\d\d\d$ ?
O que eu defendo é que se alguém nessa altura do campeonato vai querer aprender yet another framework web in Java, então esse framework terá que ser o mais simples possível, idiot-proof, com uma documentação clara e objetiva, exemplos, etc.
Se o cara achar só um pouquinho complicado, engessado, obscuro, complexo, então com certeza ele vai abandonar e voltar para o Struts ou qualquer outra coisa da moda…
Eu vi que vc fez a validação tratar ao mesmo tempo a validação na parte do cliente e na parte do servidor. Bom, isso é mais poderoso mas tb muito mais complexo de o cara entender. Eu preferiria separar isso, primeiro porque nem todo mundo vai querer/precisar fazer a validação no cliente também e segundo porque facilita para um mero mortal entender.
De novo caímos no objetivo do framework. Ele quer ser usado por vários pessoas de todos os cantos e com todos os tipos de necessidades? Ou ele tem um target de projeto e comunidade específicos?
Primeiro é necessário definir bem o conceito de arquitetura para que não se confunda com o de framework. Esses conceitos podem parecer semelhantes mas são muito diferentes! Também é importante conhecer como as decisões de escolha das “arquiteturas” são conduzidas para que se possa falar a respeito.
Então o fato de se utilizar a mesma “arquitetura” em mais de um projeto pode não ser ruim ? Hummm.
Os frameworks utilizados pelo Atena estão mesmo defasados ?
Então reúso é bom ?
[quote=pcalcado]
O terceiro e tão importante quanto é que a arquitetura deve ser testável e executável.[/quote]
Como disse, os componentes do Atena são todos POJOs.
Ainda sobre validacoes, vi que estão usando o WebWork ou Strtuts 2 da na mesma. Estão usando a validacao dele? Se não estao existe algum motivo? Pra mim é um sistema de validacao muito bom, da pra fazer validacao ajax, client ou server facil.
Um framework faz parte da arquitetura então ele influencia nela. Não há como impor o uso de um framework e criar boas -ou razoáveis- arquiteturas para todos os projetos.
Logo…? Onde você quer chegar? Onde eu falei que reuso é ruim ou algo do tipo? Uma coisa é ter um objetivo nobre, outra coisa é atingi-lo.
A arquitetura dele está defasada. Até agora eu só vi código de vocês nos tutoriais então não sei o que usam por baixo além de JPA mas a falta de testabilidade fora do container é um problema, e isso deriva do código que foi criado pelo framework de fato, o resto é JPA.
Ainda usando JPA, pelo menos no tutorial, vemos uma classe de negócios (o que vocês chama de EJB) que segundo o mesmo “EJBs representam as classes de negócio propriamente ditas. O EJB é a classe que armazena os códigos negociais e que possui a lógica de armazenamento e de consulta ao banco de dados.” e uma classe de dados, que vocês chama de Entity que segundo a documentação “Quando o objetivo for o desenvolvimento da versão real do sistema, sempre se começa a codificar pelas entidades de negócio. Essas entidades representam as tabelas do banco de dados.”. procure sobre BO/VO e você verá os problemas disso.
Basicamente vocês pegaram o Struts 2 e puseram a pior limitação do Struts 1, que é a dependência do container, e pegaram o EJB 3 e transformaram em EJB 2.x, colocando lógica em Session Beans e dados em Entity Beans. Sim, a arquitetura está defasada. Alguns anos. Por isso que nos últimos posts eu sugeri que lesse sobre outras arquiteturas e visse o que a indústria está fazendo.
[quote=jonatas@pgr.mpf.gov.br]
Como disse, os componentes do Atena são todos POJOs.[/quote]
Não, não são. Eles podem não estender ou implementar interfaces mas não podem ser utilizados fora de um container, como você mesmo disse acima.
A definição da arquitetura dos projetos do MPF é realizada baseada em critérios técnicos, não políticos.
O Atena é resultado de nossas experiências (somente nossas) no desenvolvimento de sistemas; ele é a consequência natural desse processo, não a causa.
O Atena não foi projetado para atender a todos os casos, mas para circunstâncias bem específicas do MPF.
As tecnologias adotadas pelo Atena podem não ser as mais modernas do mercado; isso não é fundamental para nós. O importante é ter resultado comprovado e pessoal qualificado para utilizá-las.
Ter um framework de referência é importante para nós (pode não ser para mais ninguém) porque traz consequências positivas para o nosso processo de desenvolvimento. Não falo de teoria, falo de prática.
Muitas das decisões que foram tomadas no Atena podem não ser as melhores (até por isso que estamos na 4a. versão), mas foram as melhores para a equipe do projeto naquele momento.
Enfim, ninguém está querendo dizer que o Atena é melhor do que nada. Só, humildemente acho, que ele tem idéias interessantes.
