Skip to content

Seis anos e muito para fazer

14 de Março de 2012

Eu venho trabalhando no projeto MiddleHeaven ha 6 anos, mesmo quando não tinha esse nome. O projeto nasceu da experiencia em cria frameworks nas empresas por onde passei e identificado padrões mais usados em sistemas reais. Claro que o tempo livre para me dedicar ao projeto diminui todos os anos já que o projeto não tem retorno financeiro o que significa que ainda é um hobbie.

Mas em 6 anos muita coisa mudou no mundo java. Do java 5 passamos para o 7  e logo, logo o 8. A plataforma EE evolui muito e se tornou muito mais parecida com o Spring. A produtividade do MiddleHeaven está na manutenção e na migração de plataforma e não necessáriamente na criação do projeto. Não que demore para por o sistema no ar, mas a configuração básica do Middleheaven não é tão básica assim, já que é preciso ligar todas as peças do puzzle. Isto levou à construção de mecanismo de injeção e o spring não foi usado porque na época não existia um mecanismo programático para o usar, o que já existe hoje.  E com o conceito de Environment (diferente do que foi adicionado no spring 3.0) que ligado em paralelo ao mecanismo de injeção as coisas ficam um pouco complexas. Em cima disso o MiddleHeaven ainda oferece suporte a modulos e controle de licença, o que complica ainda mais a inicialização.  Funciona, mas neste ponto com certeza é complexo de explicar e sem entender este ponto é mais complexo alguém se juntar ao projeto.

Então o  esforço agora é parar um pouco nas funcionalidades e tornar o framework mais amigável e mais simples. As estruturas core do projeto estavam muito complexas e de certa forma isso minava o progresso porque a toda a hora o grilo falante está lá para alertar do problema.

Outro problema é o escopo. Para ter um framework completo end-to-end que se possa adaptar aos ambientes e aos estilos de design do usuário e ao mesmo tempo ha que seguir padrões, fazer documentação , melhores práticas, etc… é complexo. O passo marco inicial é ter uma versão do Middleheaven que possa prover estrutura de sites web rodando apenas em web-container. Isto atenderá a maioria dos projetos.  Aqui, outros frameworks com mais reputação e mais tempo no mercado serão a competição. Mas a proposta do MiddleHeaven é diferente e espero que isso possa, pelo menos, aguçar a curiosidade de alguns.

Falando de diferenças e completando o meu post anterior, o processo de reescrita da camada de persistencia está terminado. Agora existem duas camadas onde antes existia uma. A maioria dos projetos hoje em dia lida com ORM e com o mapeamento dos objetos de dominio para as tabelas do banco de dados. Sempre foi preocupação do MiddleHeaven não restringir o processo a tabelas de banco de dados relacionais. Por outro lado, a experiencia mostra que em certos casos não queremos usar ORM. O cenário clássico é quando estamos fazendo relatórios. Queremos ter mais flexibilidade em como montar os dados.

Com base nesta destinção nasceu a toolbox de DataSet. Esta nova API permite controlar o mapeamento de dados logicos (chamados dataset) para os dados fisicos (tabelas para começar). Em cima da API de DataSet fica a API de ORM que já existia, mas agora todo o processamento de SQL e afins foi para a API de DataSet.

Por quê isto ? Porque ficou patente que nem sempre o dominio iria ser mapeado para tabelas e escrever um ORM para cada tipo de persistencia seria mais demorado e complexo ( embora ainda, seja uma estratégia possivel) e por outro lado gostaria de permitir o use de outras formas de persistencia NoSQL, em particular o BigTable do App Engine.  O App Engine mostrou que o padrão de desenvolvimento de ORM com banco de dados nem é a única forma e que mesmo seguindo as API padrão como JPA podemos ficar de fora da corrida. Ou seja, o problema da portabilidade de aplicações entre ambientes é exactamente o problema que o MiddleHeaven quer endereçar e não  fazia nenhum sentido estar amarrado a SQL.

Ainda falta trabalho a ser feito na api de DataSet e integração com o ORM (API de DomainStorage) mas a estrutura e o refactoring já estão no lugar.

Por falar de refactoring, também ficou claro que manter todo o projeto num só jar era overkill. Então o projeto foi dividido em diferentes sub-projetos (usando o maven) para permitir melhor organização, controle de dependencias e ajudar ao deploy usando menos e menores jars.

Após esta ultima remessa de alterações no core e completar funcionalmente a API de DataSet podemos pensar em ter a versão 0.1 finalmente vendo a luz do sol.

Deixe um Comentário

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: