Fragmental

Algumas das funcionalidades do Spring 2.0 foram anunciadas na Spring Experience, uma conferência que eu e você deveríamos ter ido mas não fomos. A novidade que vou comentar aqui é a estrutura de persistência a la ActiveRecord.

Ainda agora a notícia foi postada no GUJ, mas desde cedo venho dando uma olhada na lista do Domain-Driven Design onde as pessoas estão comentando as novidades. A lista do DDD é meio cheia de altos e baixos, mas isso é importante para o público do livro já que a relação entre os Padrões Repository e Entity é sempre debatida.

Já faz algum tempo eu tenho utilizado ActiveRecords em projetos de menor porte, mas não o ActiveRecord puro e sim uma variação que eu apresento na palestra sobre Camadas (e que mês que vem vai estar disponível em forma de artigo).

Vamos a algumas diferenças.

O ActiveRecord original não é nada mais que um objeto que conhece sua representação no Banco de Dados (geralmente uma tabela) e sabe se persistir. Muita gente usa POJOs assim (acreditando, inclusive, que faz parte dos tais “JavaBeans”). isso funciona bem para sistemas *muito* simples.

Falando um pouco do badalado Rails, a implementação de ActiveRecord da RubyForge é uma adaptação do padrão original mas aproveitando o dinamismo de Ruby. Este framework te proporciona facilidades para usar Herança, validação, busca e tudo mais. Também é limitando na escolha do modo como classes são mapeadas para o BD, mas ainda é mais escalável que a implementação original.

A minha implementação em java geralmente se baseia em ter um objeto que conhece seu Repository.

A interface do Repository é da Camada de Negócios, então é algo como ListaUsuarios em vez de UsuarioDao. O que isto implica? Para seus objetos de negócio, aquilo é uma lista, não importa se é persistida ou não. Lembre-se que para objetos de negócio não deve existir (ou pelo menos deve-se esconder ao máximo) a questão da persistência e volatilidade dos objetos. Para a Camada de Negócios ideal os objetos são sempre persistentes.

Essa interface é implementada por um DataMapper em Java EE isto quase sempre significa um DAO.

Então nós temos um objeto que possui métodos como save() e delete(). Isso facilita muito a manipulação destes pela Camada de Aplicação do seu sistema, que precisa apenas chamar os métodos desejados e depois o método de persistência, save() ou delete() (sim, a presença de um método save() é vazamento de lógica de persistência, mas neste caso não existem muitas alternativas viáveis). Toda consulta é feita ao DataMapper, como no modo tradicional.

O grande problema desta abordagem é que ela só funciona com um mapeador O-R decente por trás, como Hibernate. Fazer isto ser performático em JDBC é muito complexo, mas para sistemas que não vão crescer pode valer a pena. Meus planos incluem em um futuro próximo implementar ou pesquisar uma bibliotequinha para estes casos simples onde LazyLoading e atualizações seletivas são um luxo desnecessário.

O uso de Depedency Injection também faz muito sentido neste cenário. Existem duas alternativas básicas: mapear suas entidades como beans gerenciados pelo Spring ou utilizar uma Factory.

Quando o objeto é um serviço, eu mapeio no Spring, quando é uma classe de negócios normal, como Usuario, Pedido, etc., eu uso factories. É apenas uma questão pessoal de odiar mexer em XML, na verdade as duas opções usam Factories. Usando Spring você usa uma Factory genérica do framework que você tem que configurar, na segunda você cria uma Factory que precisa setar os valores do objeto criado (note que sua Factory deve ser um bean do Spring).

Voltando ao Spring, agora você pode marcar uma classe com uma annotation

@SpringConfigured("“)

indicando ao AspectJ que esta é uma classe gerenciada, mas que vai ser inicializada fora da BeanFactory. Note que "“ deve ser obviamente o id de um bean configurado no seu arquivo XML.

Traduzindo: em vez de utiliza o Spring com ApplciationContext/BeanFactory, você pode simplesmente fazer um :

Meubean b = new MeuBean();

Automaticamente seu Bean já estará configurado.

Muito bom isso, especialmente porque um dos grandes problemas que enfrento com Spring é o “entry point”. Se você não utilizar uma (das muitas) tecnologia(s) como Struts, WebWork, JMS ou qualquer coisa que já seja integrado ao framework, vaia cabar utilizando ApplicationContext.getBean() mais do que deveria.

Problemas? AspectJ. Para que funcio, é preciso que o pós-compilador do AspectJ rode antes nas classes. Isso realmente é *muito* ruim, mas a menos que exista um meio de obtêr um hook na JVM para a chamada ao new, não tem como ser evitado, creio.

Uma coisa engraçada de notar sobre o Spring é que agora que IoC atingiu a massa, nos círculos mais fechados de tecnologia não se tem falado muito dele, mas de outras coisas. É o ciclo sem fim da tecnologia de ponta…

Meu medo hoje é ele seguir exatamente o esquema do EJB 3.0 para configuração. Eu gostaria muito de ter uma alternativa que não enche meu código de negócios com configuração de aspectos. Espero que o Rod Johnson e cia continuem utilizando annotations como tags sempre. Se você está se perguntando “por que me importar com que rumo este framework toma? que venha o EJB3!” lembre-se que o Spring e as idéias que foram documentadas no livro do Rod Johnson mudaram a forma como as aplicações Java EE são escritas há alguns meses atrás, e provavelmente se você pensa isso agora pensava o mesmo antes.

Ainda estou lendo sobre o novo release e vou psotando aqui impressões mais itneressantes, mas é muito elgal saber que mais gente fora do mundo Rails acha que classes com save() e delete() podem ser legais…