Outro tópico que vem aí é a criação de relatórios com iReport e com JSF, duas abordagens diferentes.

1. Criar uma aplicação JEE 6 Web
2. Adicionar Java Server Faces 2
3. Criar uma classe de Entidade

Nesta hora o Netbeans pergunta se você não criar uma unidade de persistência e você pode escolher a infraestrutura que quer. Eu escolhi Hibernate JPA2. Até aí tudo bem, mas acontece que o Hibernate que está incluído é a versão 3.2.5 que NÃO contempla essa especificação.

Quando mandamos gerar os session façades para a classe de entidade o resultado são duas classes: AbstractFacade e um [Nome da Entidade]Facade. O problema é que como escolhi a versão JPA2 o wizard tenta criar as consultas usando um CriteriaQuery e isso só tem na versão JPA 2.

Estou ainda vendo como contornar isso de forma civilizada (ou seja, fácil). Assim que descobrir vou postar um roteiro aqui.

De lá para cá muita coisa mudou, embora algunas daqueles livros continuem válidos. Resolvi então colocar aqui uma lista dos livros que um desevolvedor Java EE da atualidade deve ler para conseguir dominar esse ambiente, pelo menos são os livros básicos

1. Utilizando UML e Padrões do Craig – livro obrigatório porque discute o que é desenvolver sistemas, fala de padrões de projeto e de como fazer a análise
2. Java Persistence com Hibernate – detalha como funciona a API de persistência do Java, mas utiliza muitos detalhes relacionados ao Hibernate. O livro é muito bom porque discute em detalhes todos os problemas relacionados ao uso de bancos de dados relacionais com linguagens de programação orientadas a objetos.
3. Core Java Server Faces -  apresenta o framework da Sun para o desenvolvimento de aplicações web, desde que comecei a usar o JSF não quero mais saber de Struts não vou falar mal do Struts porque usei muito no passado, mas o JSF realmente é um modelo mais robusto e interessante. Este livro cobre todos os detalhes de como usar e como escrever uma aplicação completa.
4. EJB3 em Ação – Nenhuma aplicação Java EE está completa sem o uso de EJB, que é o modelo de componentes proposto pela Sun para a linguagem Java. Neste livro aprendemos como usar a especificação mais recente e como o uso de anotações facilita a vida do desenvolvedor que fica livre de muitos arquivos XML.
   
5. EJB3 Profissional: Java Persistence API – Um complemento ao livro de Hibernate, neste livro o leitor vai achar material relacionado apenas a especificação o que é muito bom porque, como costumo trabalhar, pode-se ficar totalmente independente da implementação de persitência.
6. Desenvolvendo Relatórios Profissionais Com iReport Para Netbeans IDE – Como toda aplicação precisa de relatórios para estar completa, nada como usar uma ferramenta poderosa e baseada em ambiente gráfico para escrever os seus. Neste livro, aprendemos a usar o plugin para Netbeans de forma gradual e bem detalhada.

Mas é exatamente disso que os testes de usabilidade tratam, e no final das contas, temos mais é que testar isso tudo mesmo! Eu acho que quanto mais fácil se tornou desenvolver os sistemas, mais preguiçosos ficamos. Explico. Fácil de desenvolver porque hoje temos ferramentas de geração de código (que não existiam até bem pouco tempo) baseadas em padrões de projeto (que não estavam documentados até bem pouco tempo) que nos permitem simplesmente esquecer que certas partes precisam ser feitas. Muitas vezes tudo que precisamos fazer é introduzir pequenos detalhes específicos no código gerado, mas na maioria dos casos nem isso! Ficamos preguiçosos porque os sistemas cresceram, são agora corporativos, é muito menor a demanda de pequenas empresas por seus próprios softwares, com isso o analista que sai da faculdade demora a ter, se é que vai ter, contato direto com o cliente. Os analistas passam a ter um ponto focal centralizado a quem se reportam e acho que isso mascara a responsabilidade levando a uma negligência involuntária.

Antes que eu receba vários ataques de analistas raivosos, não estou aqui falando que todo analista de sistemas (e neste caso estou considerando a dualidade analista/programador) sejam negligentes. Embora eu já tenha trabalhado com muitos que eram realmente negligentes, estou falando aqui de uma negligência involuntária, é mais uma coisa de não fazer porque a percepção é de que o software é para uso próprio e poderemos conversar com o usuário e explicar.

Mesmo que o software seja para uso da própria empresa deve ser desenvolvido com todo o cuidado. Você pode ler mais sobre as minhas impressões sobre análise em:

• Como se faz análise
• Antes de resolver, defina o problema
• Artesanato de Software

Mas agora de volta aos testes de usabilidade. Um problema que temos com os sistemas corporativos é que são muito difíceis de testar pelo alto grau de dependência entre as partes, dessa forma, os testes unitários são quase testes de integração. Uma alternativa é fazer os testes unitários das camadas mais básicas de forma a garantir que estas estão funcionando de forma que os testes das camadas superiores possam se basear nessas camadas, mas se fizermos isso quebramos a possibilidade de paralelizar nossa equipe já que não haverão módulos básicos suficientes para todos. O que acaba ocorrendo é que as pessoas codificam antes de criar seus testes (acredite o Test Driven Development funciona!) e acabam por nunca mais fazer os testes.

Além disso os sistemas corporativos têm uma tendência forte a serem baseados em arquitetura Web ou SOA precisando estar instalados em um servidor de aplicação para executar, o problema disso é que a fórmula:

(a implantação do sistema em um servidor + iniciar o servidor de aplicação) * (obter referências aos componentes a serem testados + executar os testes)

Não é facilmente incluída nos scripts de testes unitários. O que estou pensando em adotar é um esquema de testes semiautomatizado, ou seja, a parte de iniciar o servidor e implantar a aplicação é feita manualmente, a parte de obter referências e executar testes é feita com JUnit.  Até existe um framework JSFUnit, mas infelizmente ele tem uns problemas com o ICEfaces, eu até achei o ponto onde é o problema (depois de baixar o código fonte do JSFUnit e do ICEFaces dos repositórios e gastar umas 4 horas nisso direto), mas precisa de uma modificação no código que ainda não tive tempo de implementar e testar. Embora esta seja uma parte importante, ainda assim não testaria todo o sistema, porque não resolveria a parte dos EJBs e depois de testar com EJBUnit (e mais alguns vários) chegamos a conclusão que não existe um suporte efetivo para essa camada.

Um pouco dessa dificuldade vem do fato que os frameworks *Unit são ferramentas independentes, se a Oracle/Sun adotassem o *Unit como padrão da implementação do Java isso seria incrível para os desenvolvedores, isto porque toda vez que saísse uma nova versão da plataforma e suas especificações já teríamos uma ferramenta de testes para usar.

Estou realmente achando que essa coisa de testes unitários semiautomáticos pode dar certo para a camada EJB.

Uma outra alternativa mais radical (e que na verdade eu gosto muito) é fazer o sistema todo isolado de tecnologias específicas tal como EJB, ou seja, as regras de negócio ficam em classes puramente Java, também conhecidos como POJO – Plain Old Java Objects – algo que em português seria (livremente) traduzido para Bom e Velho Objeto Java. Isto funciona porque os POJOs podem ser facilmente testados com JUnit básico, e se você usar o EJB apenas para envolver os POJOs então você garante que as regras de negócio estão sendo testadas o que já é um grande alívio. Mas porque então não tem muita gente fazendo isso?

Para separar as regras de negócio você terá mais uma camada, mais um nível de indireção e consequentemente mais classes para gerenciar. Acredito que esta seja a maior barreira para se adotar essa prática, mas eu vou criar um sistema de testes (digo sistema, porque para testar esse tipo de coisa não adianta criar uma classezinha de teste) para avaliar o impacto de se criar essa camada extra.

Outro fator é que muitas vezes as regras de negócio têm dependências de dados que precisam ser supridas, se você conseguir prever todas as necessidades de acesso a banco de dados por exemplo e executar isso antes de chamar o método fica mais fácil de tratar, mas as vezes precisamos fazer uma busca em banco no meio de um processamento de regra de negócio. Aí começa o dilema, porque se você usa JPA com EJB, então terá uma dependência do servidor de aplicação para resolver isso e quebramos a automatização do teste de novo. É claro que você pode usar Mock Objects, uma técnica de fornecer objetos que fingem ser os que realmente precisamos para efeitos de teste, mas ainda assim você terá uma proliferação de classes muito grande.

Assim que eu tiver resultados vou colocar aqui.

Em JPA temos um conjunto de anotações (aquelas marcações que colocamos em Java com um @ na frente) que servem para identificar o comportamento dos objetos na hora de gravar em banco. Vamos começar com uma bem simples, uma referência @OneToMany (ah sim, um pouco de conhecimento de inglês vai ajudar muito nessa hora!)

Em uma relação @ManyToOne estamos indicando que a classe de origem tem uma referência para um objeto da classe destino, e que este último pode ser referenciado por vários objetos da classe de origem. Exemplo, Livro tem uma Editora (não vou discutir detalhes de modelagem, se é a melhor ou não, apenas um exemplo ) então em Livro teremos um atributo do tipo Editora, agora podemos colocar a anotação correspondente:

Exemplo:

@Entity
public class Livro implements Serializable{

   @Id
   @GeneratedValue(strategy = GenerationType.AUTO)
   private Long id;
   private String titulo;
   private String autor;
   private String isbn;
   private int numPaginas;
   @ManyToOne
   private Editora editora;

   //aqui vem o resto do código
}

Outros tipos de relação são: @OneToOne, @ManyToOne e @ManyToMany. Além disso podemos ter relações unidirecionais, como no caso do Livro Editora que apresentei ou bidirecionais, quando o objeto destino também conhece o objeto de origeme aí terá um atributo que aponta de volta. Um bom exemplo é quando temos OrdemDeVenda e ItemDeVenda, onde a primeira tem uma lista de itens, e a segunda tem um atributo único apontando para a ordem a qual pertence.

Exemplo:

@Entity
public class OrdemDeVenda implements Serializable {
   //aqui tem várias coisas
   @OneToMany(mappedBy = "ordemDeVenda")
   private List<ItemDeVenda> itens;
   //aqui tem várias coisas
}

@Entity
public class ItemDeVenda implements Serializable {
   //aqui tem várias coisas
   @ManyToOne
   private OrdemDeVenda ordemDeVenda;
   //aqui tem várias coisas
}

O que podemos ver então é que no caso de uma relação OneToMany bidirecional, ela terá um complemento ManyToOne, bem razoável Existem na verdade muito mais opções para marcar, mas isso já é um começo para permitir algumas experiências. Uma nota importante, no Netbeans, quando você coloca um atributo em uma entidade ele já pede para que você marque o tipo de relação e aí basta escolher, inclusive se for bidirecional o Netbeans muda a outra classe para incluir o atributo correspondente.