Rafael Carneiro

Um pouco de conversa

Sempre que posso, acesso o fórum do Javaranch para ver as novidades e assuntos interessantes do mundo Java. No feriado de ontem estava eu navegando nesse fórum quando achei um tópico de título “When to use JSF or Struts“. Título este bem chamativo, por conta das diversas discussões e comparativos sobre esses frameworks na comunidade Java do mundo inteiro.

Nesse post, o autor pergunta qual a diferença entre os dois. A diferença é simples: a quantidade de artefatos criados e a complexidade de sua utilização. JSF é bem simples e com algumas configurações e artefatos criados já está apto para ser utilizado no seu sistema. Eu não sou xiita e não estou dizendo que JSF é melhor do que Struts ou qualquer outro framework, não estou afirmando que ele é a bala de prata. E não é.

Gostei muito de uma resposta desse post e ainda bem que ela foi logo a primeira resposta, evitando que outras respostas mudassem os pensamentos e opiniões dos leitores. Nessa resposta, o autor enfatiza: “How to choose? For me, I’ll choose a framework that team members familiar with“. Essa resposta foi bem coerente, pois se sua equipe possui experiência e produtividade com o framework X, não quer dizer que se adotar o framework Y aumentará a produtividade da equipe, pelo contrário, pode acontecer o inverso, já presenciei casos desse tipo.

É comum ver em fóruns, listas de discussão e até mesmo no dia-a-dia, profissionais discutindo com seus companheiros de trabalho, alegando que o Struts (versões 1.x) é obsoleto e está ultrapassado. Isso não é mentira, é fato. Porém o que não concordo é esse xiitismo e essa generalização em volta desse assunto. Você já trabalhou com Struts, já ganhou muito dinheiro com ele, eu também. O framework Struts foi por muito tempo o framework padrão de mercado, exigido por quase todas as empresas como requisito fundamental no currículo. Acredito que apenas uma fatia dos novos desenvolvedores que iniciaram a pouco tempo não tiveram a chance de trabalhar com ele. Mas este dia chegará, pois muito em breve esses teenagers irão prestar consultoria em sistemas que foram feitos com esse framework.

Por que o Struts está obsoleto?

É muito simples de explicar. Veja a imagem abaixo e tente comparar com qualquer outro framework da moda.

Essa arquitetura é completamente orientada a BOLOVO. Note que é necessário a criação de vários artefados para a criação de um simples caso de uso.

Artefatos necessários:

1. configuração do Servlet Front Controller do Struts no deployment descriptor (web.xml)
2. criação de um XML denominado struts-config.xml
3. criação de uma classe Java que estende a classe ActionForm (Struts)
4. criação de uma classe Java que estende a classe Action (Struts)
5. configuração do ActionForm no struts-config.xml
6. configuração da Action no struts-config.xml
7. se você for utilizar validação (que é necessária em todo sistema que se preze), é necessário a criação de outros artefados, como por exemplo um arquivo de propriedades.

Isso não acontece com frameworks da moda, nos quais são orientados a POJO. Por exemplo, o JSF necessita apenas da criação de uma classe POJO, configuração do Servlet no deployment descriptor e da criação de um XML chamado faces-config.xml. Três artefatos criados, eu disse apenas três artefatos criados.

Portanto, a sua utilização poderá acarretar em futuros problemas, como inúmeras refatorações. Também existe uma má utilização dos princípios da Orientação a Objetos e péssimas práticas de desenvolvimento de software, nos quais posso citar algumas: alto acoplamento, alta manutenabilidade e complexidade.

E agora, o que utilizar?

Muita calma nesta hora. Como mencionei acima, não sou xiita (a-rá, gosto de EJB e irei utilizá-lo em todos os meus projetos, até um hello world numa simples JSP, criarei diversos artefatos, farei várias configurações e utilizarei um servidor de aplicações parrudo). Ratificando: o intuito deste post não é mostrar que o framework X é melhor do que o framework Y.

Java está se tornando uma plataforma difícil de se dominar, por ser bastante abrangente e surgir novas funcionalidades todos os dias. Sem falar de frameworks, que todo dia nasce um no quarto de um desenvolvedor que está com seu ócio criativo em alta. Mas alguns frameworks estão me chamando bastante atenção, por serem produtivos, robustos e simples. São eles: JSF, VRaptor e Spring.

Lembrando mais uma vez: nenhum framework é a bala de prata!

Outros frameworks que estão chamando atenção da comunidade: Apache Wicket e Waffle. Implementações: Jersey e Metro.

Sobre frameworks caseiros

Se você acessar os maiores fórums brasileiros de Java como GUJ e PortalJava, verá inúmeras discussões sobre as vantagens e desvantagens de frameworks caseiros. Particularmente eu vejo muitas desvantagens, pois já passei por uma experiência que não me agradou muito. Há uma discussão no GUJ sobre esse assunto, ela é datada de 2005, que me chamou bastante atenção. Se em 2005 alguns dos membros mais ativos da comunida Java já falaram das desvantagens de construir tal geringonça, por que após três anos isso ainda continua?

Frameworks caseiros não são arquiteturas de referência, não são padronizados, não possuem uma comunidade em volta para dar apoio e não são padrões da insdústria de software. Construir frameworks caseiros com o dinheiro público é o pior caso de todos.

Nesse post do GUJ, Carlos Villela comentou:

Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.

Ele adivinhou o que poderia acontecer utilizando essa abordagem e eu tive a péssima experiência de passar por isso.

Não sendo xiita, afirmo que cada caso é um caso. Está certo que em determinados projetos é necessário construir um determinado número de classes que executam processos comuns entre sistemas. Mas é para ser feito só o básico e o necessário, nada mais além do que isso, porque senão irá virar um framework!

Referências

• Entendendo Domain Driven Design, por Rafael Ponte
• Comparing Web Framework, por Matt Raible

Tenho visto em fóruns pessoas com dificuldade em obter os objetos HttpServletRequest e HttpServletResponse utilizando o Struts2. A action do Struts2 é um POJO e não possui acoplamento e dependência com os objetos dos containers. Mas o framework disponibiliza algumas classes que fornecem esses objetos. A classe ServletActionContext é uma delas, então vamos aos códigos.

Código:

//imports e definição da classe

HttpServletRequest request = ServletActionContext.getRequest(); //obtendo o objeto HttpServletRequest

HttpServletResponse response = ServletActionContext.getResponse(); //obtendo o objeto HttpServletResponse

O Struts2 disponiliza ainda outras formas de obter alguns objetos comuns da especificação Servlet, como a classe ActionContext, que fornece métodos que retornam o contexto da aplicação, mapa da sessão, etc.

Até a próxima!

Como prometido, irei iniciar uma série de posts sobre o Struts2. E para começar, vamos aprender a configurar o básico para a sua utilização em projetos.

Primeiro, crie a estrutura de diretórios abaixo (como IDE utilizei o Eclipse) e baixe o arquivo struts-2.0.9-lib.zip, precisaremos das libs mostradas na imagem.

Web.xml

Edite o web.xml do seu projeto e adicione as linhas abaixo. A classe FilterDispatcher é o filtro do Struts2, ela é responsável por todas as requisições da aplicação.
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
</filter>

<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

struts.xml

Esse é o arquivo de configuração, onde ficam as informações como: actions, forwards, interceptors, plugins, etc. Por questão de visualização e organização, criei o arquivo helloworld.xml para manter o arquivo de configurações do Struts2 mais legível. Não era necessário criar esse arquivo (helloworld.xml), porém já imaginou o tamanho que seria esse arquivo em um projeto real?

<struts>

<constant name=”struts.enable.DynamicMethodInvocation” value=”false” />
<constant name=”struts.devMode” value=”true” />

<include file=”helloworld.xml”/>

</struts>

helloworld.xml

Principais atributos:

• package name: nome do pacote;
• namespace: nome no qual poderá ser utilizado nos formulários e nas URLs ;
• action name: atributo que define o nome da action
• class: caminho completo da action
• result name: nome para o forward ou resultado. Informa para qual JSP a página será direcionada.

<struts>
<package name=”helloworld” namespace=”/helloworld” extends=”struts-default”>

<action name=”HelloWorld” class=”org.carneirorafael.HelloWorld”>
<result name=”SUCCESS”>/helloworld/HelloWorld.jsp</result>
</action>

</package>
</struts>

HelloWorld.java

A classe HelloWorld é a action POJO (Plain Old Java Object) do Struts2. Ela estende a classe ActionSupport e sobrescreve o método execute. Possui o atributo mensagem que é uma String e tem seus métodos acessores. Ao chamar a URL http://seuHost:suaPorta/strutsbegin/helloworld/HelloWorld.action o método execute é chamado e este configura o atributo mensagem, através do método acessos setMessage.

//imports

public class HelloWorld extends ActionSupport {

private static final long serialVersionUID = 7407988331733714918L;

private String mensagem;

@Override
public String execute() throws Exception {
this.setMessage(”HelloWorld com o Struts2!”);
return “SUCCESS”;
}

public String getMensagem() {
return this.mensagem;
}

public void setMessage(final String message) {
this.mensagem = message;
}
}

HelloWorld.jsp

E por fim, a JSP na qual exibirá os dados na tela através da tag <s:property>. Essa tag pega o valor do atributo mensagem que se encontra na action.

<%@ page contentType=”text/html; charset=UTF-8″ %>
<%@ taglib prefix=”s” uri=”/struts-tags” %>
<html>
<head>
<title>HelloWorld com Struts2</title>
</head>

<body>

<s:property value=”mensagem”/>

</body>
</html>

Conclusão

Está muito fácil configurar um projeto e fazer um helloworld no Struts2. E é porque eu não utilizei as anotações (annotations). Irei continuar escrevendo mais posts sobre esse framework, tentando expor suas novas funcionalidades e características. Espero que esse post possa ajudá-lo a conhecer um dos frameworks MVC mais conhecidos do mercado.

Download

Struts2Begin

Hoje estava lendo notícias no javalobby e vi uma pesquisa feita nos E.U.A sobre os frameworks web mais utilizados entre 2005 e 2007. E como todos já sabem (ou pelo menos deveriam saber), o framework web mais utilizado (que por sinal deixou os concorrentes comendo poeira) é o JSF, mais conhecido como JavaServer Faces. Há um bom tempo venho observando a quantidade de empresas que estão adotando essa tecnologia para o desenvolvimento de seus projetos, bem como o aumento de desenvolvedores que utilizam esse framework, seja em suas empresas ou em projetos pessoais.

Venho observando também o excelente leque de opções de bibliotecas feitas em cima do JSF que facilitam a vida dos desenvolvedores, entre elas: ajax4jsf e myfaces.

É interessante também observar a briga entre o Spring MVC e o Ruby on Rails.

Por que será que o Struts2 está perdendo a pouca popularidade que teve quando foi lançado? Essa pergunta será respondida em breve.

Foi lançado mais um framework MVC brazuca, o Neo Framework. A moda já pegou e a comunidade java brasileira está cada vez mais centralizada em criar seus próprios frameworks. Pessoalmente eu acho isso muito bom, pois observo que a cada dia que passa as pessoas estão caindo na real de que nós não podemos “viver presos à outras nações”, ou seja, presos aos idiomas e documentações. Não estou sendo radical, é bom e essencial para a nossa área saber inglês e outras línguas, pelo contrário, gosto muito de inglês e de bandas com letras nesse idioma. Apenas estou querendo dizer que esse lado é bom, pois valoriza a comunidade java brasileira.

Outro exemplo de framework brasileiro é o Mentawai, que está sendo bastante utilizado e eu tive o prazer de conhecer o seu funcionamento, criando alguns testes. Ele é baseado em configuração programática, sem a utilização de arquivos XML, Annotations ou qualquer outro tipo de metadata. Informo aos meus conterrâneos da terra da luz (Fortaleza) que o site/sistema do Tribunal de Contas do Estado do Ceará utiliza o Mentawai como framework MVC. A sua documentação é bastante rica, com diversos exemplos de utilização e webapps de exemplos e possui um fórum para tirar dúvidas.

Como framework MVC tem ainda o VRaptor, criado pelo pessoal da Caelum e pelos administradores do GUJ. A versão atual do GUJ, chamada de GUJ2, foi feita utilizando esse framework para a camada de controller. Sua configuração é baseada em Annotations, sua lógica é baseada em POJOs, tem integração com displaytag e suporte à frameworks de apresentação, como velocity e sitemesh.

Para o Swing, tem o framework SwingBean, de autoria do Eduardo Guerra, atual editor-chefe e colunista da revista Mundo Java. O seu intuito é simplificar a vida dos programadores desktop. Confira mais características e funcionalidades no site do projeto.

A edição número 21 da Mundo Java tem como matéria principal esses frameworks citados acima (também fala sobre o JSenna, antigo JBanana), com exceção do Neo. A edição 23 fala sobre o JSpider, uma ferramenta JavaEE brasileira.

E não acaba por aí, tem também o Spring Annotations, uma biblioteca criada pelo Rodrigo Urubatan com o intuito de configurar toda a sua aplicação em Spring utilizando annotations. Na próxima edição da revista Mundo Java terá um artigo sobre essa biblioteca. Clique aqui para conferir a documentação em português.