No céu do meio

O projeto Middleheaven continua  a passo curtos. Muita gente tem demonstrado o seu apoio. Obrigado.

A identidade do projeto talvez esteja um pouco nebulosa porque até agora o que ha para mostrar é apenas o código e um conjunto esparso de texto falando de umas coisas chamadas toolboxes. Toolboxes são como pedaços da API, como no JSE temos o JCF ,  I/O e Threads que na realidade se encaixam mas as vemos como partes separadas.

O projeto começou por ser apenas um repositorio de código que eu utilizava repetidamente. Coisas como copia de arquivo e utiltários vários. Depois passou a ser um framework. Um conjunto de coisas prontas, mas complexas. À medida que construia outros frameworks mais simples eu pensava em poder levá-los até ao limite e incorporá-los no framework. Hoje, o MiddleHeaven não é mais um framework e sim uma plataforma de desenvolvimento. Uma arquitetura e design padronizada com partes extensiveis e plugáveis e um conjunto de plugins e extensões já preparadas.

O MiddleHeaven pode-se comparar ao Spring no espirito de facilitar a programação e conexão de partes da aplicação.  Tal como o Spring o MiddleHeaven conta com um motor de injeção automática, mas à diferença do Spring ele não tem definição baseada em XML. Na ralidade não tem porque não foi implementado. O MiddleHeaven delega essa parte a um objeto especifico que pode ser implementado de muitas formas. Por agora, anotações são a base – pode escolher entre as do próprio MiddleHeaven ou as padrão como @Resource.

Ao contrário do Spring que utiliza directamente outros frameworks e não oferece nenhum encaspulamento – no sentido que você ainda tem que saber usar esse outro framework – o MiddleHeaven oferece as suas próprias estruturas e design que pode ser extentido com implementações diversas baseadas em diferentes frameworks de terceiros.  Enquanto que no Spring estes frameworks são le reason de être do motor de injeção, no MiddleHeaven eles são apenas detalhes de implementação que podem mudar ou ser substituidos.

Um outro framework com que poderiamos traçar um comparativo é o JCompany. O JCompany é um framework proprietário com uma versão livre que vai um passo além do Spring oferecendo um certo encapsulamento em torno de APIs de terceiros visando o máximo possivel aderir a padrões de mercado. O JCompany oferece muito já pronto e está mais para aplicação costumizável do que para framework propriamente dito. Contudo o conceito por detrás é muito semelhante ao do MiddleHeaven. A grande diferença é que – além da licença – o MiddleHeaven não corre atrás dos padrões de mercado. Esse é um objetivo explicito. Os padrões serão incorporados quando necessário e normalmente por debaixo dos panos já que todo o conceito do MiddleHeaven é exatamente abstrair toda essa parafernália de padrões e tecnologias que mudam constantemente.

O MiddleHeaven é fortemente baseado, não apenas em padrões , mas também em conceitos. As abstrações do MiddleHeaven tendem a ser ir o mais longe possivel para que possam ser reutilizadas o máximo possivel.  Em alguns pontos isso pode significar menor performance ou uma complexidade extra que o programador considera desnecessária, contudo, é sempre possivel não utilizar o modelo do Middleheaven ou usá-lo parcialmente. O desafio é que o programador goste de usar o modelo do MiddleHeaven porque ele é natural.

Embora eu tenha começado dizendo que o MiddleHeaven está caminhando a passos curtos isso é porque estou me referindo a todas as capacidades que foram sonhadas para ele. Contudo ele já faz muita coisa. Já é possivel desenvolver uma aplicação web no estilo do Spring MVC , o ponto que falta para fechar o ciclo e poder libertar uma versão beta ( ou talvez 0.2-alfa) é a persistencia; que está sofrendo uma remodelação.  Depois vem a parte de interação com o usuário que permitirá aplanar a diferença entre o mundo web e o desktop. Esta é a funcionalidade realmente nova do MiddleHeave,n mas  para chegar lá o básico tem que estar no lugar e ser sólido.