| Autor |
Mensagem |
|
|
Obrigado pelas últimas considerações.
Aproveito para informar que estaremos disponibilizando esta semana a versão 4.0.4 do Atena, com inúmeras melhorias.
|
 |
|
|
bzanchet wrote:Só por curiosidade... Vocês escrevem a documentação, site, tutoriais, exemplos etc durante o trabalho, no MPF?
E nas horas vagas...
|
|
|
|
Bruno,
bzanchet wrote:para padronizar essas coisas, não é preciso escrever um framework
Concordo integralmente com você quando você diz que para se ter padronização não é necessária a criação de um framework. Mas não foi isso que fizemos!
Para que você entenda, tudo começou com a definição de uma arquitetura para um projeto específico. Essa definição levou em consideração um ou outro componente reutilizável que tínhamos desenvolvido, mas essencialmente, se limitava a frameworks open-source como Struts e Hibernate. Mas aí vieram o segundo e o terceiro projeto e acabamos por criar componentes para realizar tarefas que antes, ou eram difíceis de fazer, ou eram repetitivas, ou levavam muito tempo. Essas extensões a esses frameworks, que foram amadurecendo a cada projeto, é que resultou no Atena.
Então, não é que tenhamos escrito um framework para que fosse utilizado pelos projetos. O que aconteceu foi uma conseqüência natural de nosso processo de desenvolvimento.
bzanchet wrote:dizes que impor o Atena...
Mais uma vez. Não existe imposição quanto ao uso do Atena, se ele não atender aos requisitos dos usuários. Mas veja, estamos falando de relações custo-benefício. Se hoje somos capazes de desenvolver sistemas a custo bem menores com o Atena, o que justificaria não utilizá-lo ? Como é que se defende uma idéia dessas para um gestor ? (veja o post do pbnf!)
bzanchet wrote:não fala de inovações técnicas, de novas abordagens
Vamos lá!
Com relação à camada de controle:
* O Atena possibilita a configuração do struts.xml por meio de anotações (suportado parcialmente pelo Struts)
* O Atena adiciona o escopo de "action" aos já existentes (request, session, application)
* O Atena permite a injeção e conversão de dados da requisição em campos de tipos genéricos na action (não suportado pelo Struts)
* O Atena trata requisições síncronas e assíncronas exatamente da mesma forma
* O Atena tem um registro único, em java, de validações a serem aplicadas nos lados cliente e servidor
* O Atena tem anotações para injeção do usuário e do domínio (contexto da autenticação) corrente nas actions
Com relação à camada de visão:
* O Atena permite prototipação em java com reaproveitamento de código
* Todas as interfaces visuais do Atena são construídas em java
* Com isso, podem ser criados componentes de diversas granularidades
* Componentes podem herdar ou conter outros componentes (como pensar em herança com JSP ?)
* O Atena possui componentes do tipo "CasoDeUso" que encapsulam diversas páginas em um só componente
* Nenhum JSP é necessário
* O Atena permite a utilização de skins (substituição de templates do Velocity)
Com relação à camada de negócio:
* O Atena permite a execução de códigos compatíveis com a especificação EJB 3 dentro e fora de um container EJB
* O Atena possui tipos customizados (Data, Hora, Moeda...) que encapsulam conversões e formatações
* O Atena permite o armazenamento de comandos EJB QL em repositórios XML ao invés de em código
* O Atena permite sintaxes como "select pessoa from Pessoa pessoa [where pessoa.nome like :nome] order by pessoa.nome"
Isso pra citar alguns dos recursos.
[]s
Godoi
|
|
|
|
boaglio wrote:
Eu sugiro que para resolver esse problema você considere o uso do Maven no projeto.
Estamos considerando e provavelmente iremos usar.
boaglio wrote:
Uma pergunta: na decisão de framework MVC, não se pensou em usar outra coisa além do Struts , como Mentawai , VRaptor ou Spring MVC ?
A decisão pelo Struts foi baseada nos recursos disponíveis no framework (obviamente), na experiência dos desenvolvedores do MPF, na mão de obra disponível no mercado e em casos de sucesso. Não faria sentido para nós usar uma tecnologia que ninguém conhecesse (aqui dentro, digo) ou que não fosse considerada madura o suficiente pela equipe. Mas isso não significa que utilizaremos o Struts sempre nem em todos os projetos. Apenas nos preocupamos que essas mudanças aconteçam de maneira responsável, gradual e com o menor impacto possível para a instituição.
[]s
Godoi
|
|
|
|
Obrigado pelas manifestações de apoio.
Para esclarecer a questão dos testes: provavelmente nunca será preciso estender actions ou classes de negócio para a realização dos testes, apesar de ser teoricamente possível em alguns casos. O projeto a que fiz referência nos primeiros posts possui classes auxiliares, como TestCases, e mocks para a simulação da execução das aplicações fora de um container de servlet. De qualquer forma, são todos helpers que podem ou não ser utilizados. A analogia com o MockStrutsTestCase é que não foi feliz.
[]s a todos
Godoi
|
|
|
|
|
eu também.
|
|
|
|
Teoricamente, pode ter sua utilidade.
In a unit test, mock objects can simulate the behavior of complex, real (non-mock) objects and are therefore useful when a real object is difficult or impossible to incorporate into a unit test. If an object has any of the following characteristics, it may be useful to use a mock object in its place:
* supplies non-deterministic results (e.g. the current time or the current temperature);
* has states that are difficult to create or reproduce (e.g. a network error);
* is slow (e.g. a complete database, which would have to be initialized before the test);
* does not yet exist or may change behavior;
* would have to include information and methods exclusively for testing purposes (and not for its actual task).
|
|
|
|
pcalcado wrote:(sobre testes) É preciso ou não?
Não. É opcional!
pcalcado wrote:Estou confuso novamente. Você descreveu o processo (até pediu opiniões!):
Descrevi uma sequencia de atividades, não disse que ela acontece apenas uma vez !!!
pcalcado wrote:Que bom.
Que bom que concordamos em algo!
[]s
Godoi
|
|
|
|
(com alterações)
pcalcado wrote:
E o que o framework faz, afinal? Lá no primeiro post desta thread temos mais da metade das características (ou funcionalidades) providas pelo mesmo que derivam de utilizar JPA e/ou o modelo de programação do tutorial. Se eu abrir mão do atena e utilizar apenas Struts 2 normalmente o que eu perco?
O Atena é uma extensão dos frameworks citados. Ele contém funcionalidades adicionais que podem ou não ser utilizadas. Por exemplo, há quem prefira manipular o arquivo "struts.xml" para fazer a configuração dos fluxos. No Atena, essa configuração é realizada por meio de anotações na action. Melhor do que eu falar dos recursos do Atena, é consultar a documentação do projeto.
pcalcado wrote:
- Então porque você tem que criar um mock para realizar um simples teste unitário fora de um container?
Isso não é necessário para testes unitários, mas para testes de simulação da execução da aplicação em um container.
pcalcado wrote:
Sobre o processo de desenvolvimento que você descreveu ele é o processo waterfall, desacreditado há mais de vinte anos (inclusive pelo seu criador). Procure ler sobre modelo iterativo incremental de desenvolvimento, especialmente com vertentes ágeis para entender o que o mercado tem feito nas últimas décadas.
Mais uma vez você se refere a um processo que não conhece. O processo em questão é sim iterativo e incremental.
pcalcado wrote:
... pode ser o ideal para algumas aplicações
Para as outras, utilizamos outras tecnologias!
|
|
|
|
Mas vamos às considerações técnicas.
1) Sobre as tecnologias abordadas
Veja, o framework Atena não define a arquitetura que será utilizada. Você pode usar EJB ou não, você pode usar JPA ou não, você pode usar Velocity ou não, você pode ter camadas a mais ou a menos, etc. A única coisa obrigatória é o Struts 2. Mas apesar disso, o Atena propõe que se façam códigos compatíveis com a especificação EJB 3 para a camada de negócio; se o sistema será implantado ou não em um container EJB é uma segunda decisão.
2) Sobre a imposição de limitações do Struts 1 e do EJB 2
Isso é totalmente improcedente. Não existem tais limitações.
3) Sobre o desenvolvimento das entidades de negócio em primeiro lugar
Antes de mais nada, isso só tem sentido em relação à programação, não ao processo de desenvolvimento. Mas vamos lá, em nosso processo de desenvolvimento a equipe responsável pela implementação recebe da equipe de especificação o ambiente criado, a documentação do projeto, modelos e diagramas, os protótipos, e o banco de dados criado. A partir daí, a codificação tem sido iniciada justamente com a criação das entidades de negócio. Para nós, essa decisão faz sentido, mas gostaria de ouvir outras opiniões.
4) Sobre as interfaces de validação
A interface Validacao é a validação propriamente dita. A interface Validavel refere-se a um componente visual que pode ser alvo de validação. A interface Validante é aplicável , geralmente, a botões que podem ou não disparar a validação do formulário. E a interface Validador é aplicável ao formulário que contém os componentes a validar. Parece complexo, mas na verdade é bem simples.
5) Sobre a construção de regras de validação.
Para criar uma nova regra de validação, crie uma classe que implemente Validacao, adicione o código javascript de validação cliente à algum arquivo js do Skin em uso e pronto! Você já pode utilizá-la em suas interfaces visuais.
6) Sobre a unificação das regras de validação cliente e servidor.
A unificação dessas regras tem se mostrado mais fácil e produtivo do que quando eram separadas. Havendo necessidade de validação somente do lado servidor, basta não se fazer esse registro. Também nesse caso outras opiniões seriam interessantes.
7) Sobre a codificação das páginas em java
Esse, por mais que digam o contrário, é o maior barato! Deve-se entender bem como funciona a camada de visão para se emitir um julgamento. Essa separação dos templates do Velocity (com os códigos HTML) do código Java é que traz produtividade ao processo de desenvolvimento e permite abstrações diferentes das que estamos acostumadas. Quantas vezes vocês herdaram uma página JSP ?
8. Sobre a adição de scripts às páginas
Existem diversas formas de se adicionar scripts à página: a forma com o Maracuja falou (a não recomendada), por meio do componente Pagina, por meio de Skins (apontando para arquivos javascript), por meio de templates do Velocity, ou criando-se novos componentes que encapsulam esses scripts. Escolha a sua!
[]s
Godoi
|
|
|
|
Para evitar maiores discussões:
1) A definição da arquitetura dos projetos do MPF é realizada baseada em critérios técnicos, não políticos.
2) O Atena é resultado de nossas experiências (somente nossas) no desenvolvimento de sistemas; ele é a consequência natural desse processo, não a causa.
3) O Atena não foi projetado para atender a todos os casos, mas para circunstâncias bem específicas do MPF.
4) 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.
5) 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.
6) 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.
[]s a todos
|
|
|
|
Algumas considerações:
pcalcado wrote: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
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.
pcalcado wrote:
Pode ser a mesma arquitetura utilizada em outros projetos sem nenhuma mudança mas cada situação deve ser analisada.
Então o fato de se utilizar a mesma "arquitetura" em mais de um projeto pode não ser ruim ? Hummm.
pcalcado wrote:
O segundo critério é observar o que já foi criado pela indústria em termos de software
Os frameworks utilizados pelo Atena estão mesmo defasados ?
pcalcado wrote:
não reinventar a roda
Então reúso é bom ?
pcalcado wrote:
O terceiro e tão importante quanto é que a arquitetura deve ser testável e executável.
Como disse, os componentes do Atena são todos POJOs.
|
|
|
|
Luca wrote:Me antecipo na resposta óbvia: depende do projeto.
Ok, até aqui concordamos. Mas no que se baseia essa decisão ?
|
|
|
|
pcalcado wrote:...arquiteturas de referência, caseiras ou não, são o extremo oposto de boas arquiteturas.
Só por curiosidade, como é a boa arquitetura ?
|
|
|
|
|
Só estamos criando ferramentas para que os desenvolvedores possam testar seus códigos. Se não for preciso porque são POJOs, muito bem!
|
|
|
|
|
|