Next – A motivação para um novo framework
No desenvolvimento de aplicações JEE, geralmente temos basicamente os seguintes artefatos: um banco de dados, classes e arquivos de templates que são os JSPs. Os banco de dados são relacionais, diferente da natureza orientada a objetos das classes que dispomos. Temos então o primeiro problema: fazer a comunicação entre os objetos e o banco de dados relacional. As classes em tempo de execução são objetos que dependem e interagem entre si. Aí está o segundo problema: satisfazer a dependência entre os objetos para poderem interagir. É justamente nesse tipo de problema, que não é o problema da regra de negócio da aplicação, que podemos utilizar frameworks para facilitar o trabalho.
Para resolver o problema do mapeamento objeto/relacional temos como exemplo o Hibernate. Para resolver o problema da dependência entre os objetos podemos utilizar o Spring. Além desses problemas que surgiram apenas por necessidades arquiteturais de um sistema, no ambiente web também temos os problemas de comunicação entre cliente e servidor. Onde informações devem ser trocadas por um meio onde apenas Strings são transferidas, que é o protocolo HTTP. O próprio Spring tem um modelo MVC para ajudar a solucionar esse problema.
Com esses dois frameworks, Hibernate e Spring, podemos então solucionar grande parte dos problemas estruturais de uma aplicação. Conseguimos desenvolver em um nível mais alto, já que os problemas mais básicos estão resolvidos. Nesse nível mais alto temos agora, que integrar os dois frameworks. O Spring possui classes já preparadas para a integração com o Hibernate. Mas mesmo utilizando os recursos mais automatizados do Spring, ainda será necessário a utilização de um XML para configurar DataSources, HibernateTemplates, TransactionTemplates, etc. A mesma coisa acontece com o Spring MVC, será necessário configurar qual engine de templates utilizar, como serão resolvidas as URLs e com isso mais um XML será criado.
Se pensarmos que a única informação realmente relevante para o Hibernate e toda a configuração de persistencia do Spring são o caminho para o banco de dados e quais são as classes que serão mapeadas, ainda temos muito trabalho configurando informações que praticamente não mudam. Ou seja, as classes que serão mapeadas serão as que tiverem a anotação @Entity e o dataSource, hibernateTemplate, transactionTemplate serão configurados de acordo com o caminho banco de dados. Com base nisso as informações realmente relevantes são url, driver, usuário e senha do banco de dados. Para que tanto XML e configuração sendo que tudo é baseado apenas no caminho do banco de dados? No caso do Hibernate por exemplo, porque sempre temos que informar o dialeto sendo que o dialeto já é especifico para cada SGBD? Acho que ninguém usa um dialeto do PostgreSQL em um banco MySQL. Ainda podemos eliminar trabalho na área de persistencia.
Vamos pensar agora na camada de visão da aplicação, considerando que o usuário do sistema o utilizará através de um browser lendo HTML e conversando HTTP. A base que temos é: um servlet receberá os parâmetros e deverá montar alguma resposta com base na requisição. Utilizando o Spring MVC, elevamos essa base para algo mais interessante, com a possibilidade de mapear os parâmetros recebidos em objetos e redirecionar a requisição para um template que irá montar a resposta. A camada de controle, deve estar alinhada com a camada de visão pois o que a visão renderizar será a causa de uma nova requisição, logo os parâmetros dessa nova requisição devem condizer com que o controle espera. Quando desenvolvemos aplicações JEE a camada de visão é quase sempre JSP. O Spring MVC possui algumas tags para facilitar a montagem dessa resposta no JSP de acordo com que o controle espera. Mas essas tags não são completas.
Quando vamos montar um HTML temos alguns problemas básicos a enfrentar. O primeiro é que precisamos navegar em objetos e seus atributos para recuperar o modelo que será utilizado na renderização. Ou seja, precisamos recuperar o valor do atributo nome do objeto que está no escopo de requisição com o nome pessoa.
Depois que navegamos nos objetos disponíveis e escolhemos os atributos a serem mostrados, temos que escolher se mostramos esse valor como output, ou seja, apenas para leitura do usuário. Ou, como input, o usuário irá preencher esse valor, que deve ser lido pelo controle posteriormente. Nesse caso já vemos que o controle deve estar alinhado com a camada de visão.
As informações mostradas no HTML não podem ficar soltas, precisamos de algumas tags como DIVs ou TABLEs para organizar o conteúdo na página.
E finalmente precisamos ter algum meio de navegação, onde podemos criar formas de o usuário acessar as várias funcionalidades de um sistema.
De todos esses problemas que estão presentes na montagem de um JSP, o único que as tags do Spring implementa de forma que auxilia o desenvolvedor é a navegação entre os objetos. No ambito de escolher entre input, output, organizar as informações no HTML e ainda dar estilo, o Spring MVC não consegue auxiliar tanto. Por isso o Spring MVC não é tão produtivo para a camada MVC da sua aplicação. Mas ainda assim é melhor que um servlet puro.
Com base nesses problemas levantados, vemos que ainda restam várias brechas que os frameworks de mercado não resolvem, e talvez nem esteja no escopo deles resolver. É justamente nessas brechas que o Framework Next atua. Os problemas citados nesse artigo são resolvidos pelo Next de forma que o desenvolvedor não precise se preocupar com eles. Para configurar o Next com o Hibernate, e todos os objetos do Spring que dão suporte ao Hibernate por exemplo, basta um arquivo connection.properties que contém apenas a url, driver, usuário e senha do banco de dados. Todas as outras configurações são feitas pelo Next, você só precisará modificá-las caso necessite. Na camada de visão o Next tem um grupo de tags para trabalhar com cada um dos problemas citados. Como os problemas estão separados em cada grupo, um número pequeno de tags consegue resolver a maior parte dos problemas. O Next também melhora a camada de controle com mais suporte e integração com a camada de visão. E outras situações que não falamos aqui, como autorização e autenticação, upload de arquivos, AJAX, relatórios e casos de uso que são padrão como CRUDs também são tratados pelo Next.
Vemos que o Next não tenta reinventar a roda, ele utiliza ao máximo os frameworks de suporte e vai além, provendo uma plataforma de mais alto nível para dar mais produtividade ao desenvolvimento de aplicações JEE.
