No desenvolvimento de aplica\u00e7\u00f5es JEE, geralmente temos basicamente os seguintes artefatos: um banco de dados, classes e arquivos de templates que s\u00e3o os JSPs. Os banco de dados s\u00e3o relacionais, diferente da natureza orientada a objetos das classes que dispomos. Temos ent\u00e3o o primeiro problema: fazer a comunica\u00e7\u00e3o entre os objetos e o banco de dados relacional. As classes em tempo de execu\u00e7\u00e3o s\u00e3o objetos que dependem e interagem entre si. A\u00ed est\u00e1 o segundo problema: satisfazer a depend\u00eancia entre os objetos para poderem interagir. \u00c9 justamente nesse tipo de problema, que n\u00e3o \u00e9 o problema da regra de neg\u00f3cio da aplica\u00e7\u00e3o, que podemos utilizar frameworks para facilitar o trabalho.<\/p>\n
<\/p>\n
Para resolver o problema do mapeamento objeto\/relacional temos como exemplo o Hibernate. Para resolver o problema da depend\u00eancia entre os objetos podemos utilizar o Spring. Al\u00e9m desses problemas que surgiram apenas por necessidades arquiteturais de um sistema, no ambiente web tamb\u00e9m temos os problemas de comunica\u00e7\u00e3o entre cliente e servidor. Onde informa\u00e7\u00f5es devem ser trocadas por um meio onde apenas Strings s\u00e3o transferidas, que \u00e9 o protocolo HTTP. O pr\u00f3prio Spring tem um modelo MVC para ajudar a solucionar esse problema.<\/p>\n
Com esses dois frameworks, Hibernate e Spring, podemos ent\u00e3o solucionar grande parte dos problemas estruturais de uma aplica\u00e7\u00e3o. Conseguimos desenvolver em um n\u00edvel mais alto, j\u00e1 que os problemas mais b\u00e1sicos est\u00e3o resolvidos. Nesse n\u00edvel mais alto temos agora, que integrar os dois frameworks. O Spring possui classes j\u00e1 preparadas para a integra\u00e7\u00e3o com o Hibernate. Mas mesmo utilizando os recursos mais automatizados do Spring, ainda ser\u00e1 necess\u00e1rio a utiliza\u00e7\u00e3o de um XML para configurar DataSources, HibernateTemplates, TransactionTemplates, etc. A mesma coisa acontece com o Spring MVC, ser\u00e1 necess\u00e1rio configurar qual engine de templates utilizar, como ser\u00e3o resolvidas as URLs e com isso mais um XML ser\u00e1 criado.<\/p>\n
Se pensarmos que a \u00fanica informa\u00e7\u00e3o realmente relevante para o Hibernate e toda a configura\u00e7\u00e3o de persistencia do Spring s\u00e3o o caminho para o banco de dados e quais s\u00e3o as classes que ser\u00e3o mapeadas, ainda temos muito trabalho configurando informa\u00e7\u00f5es que praticamente n\u00e3o mudam. Ou seja, as classes que ser\u00e3o mapeadas ser\u00e3o as que tiverem a anota\u00e7\u00e3o @Entity e o dataSource, hibernateTemplate, transactionTemplate ser\u00e3o configurados de acordo com o caminho banco de dados. Com base nisso as informa\u00e7\u00f5es realmente relevantes s\u00e3o url, driver, usu\u00e1rio e senha do banco de dados. Para que tanto XML e configura\u00e7\u00e3o sendo que tudo \u00e9 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\u00e1 \u00e9 especifico para cada SGBD? Acho que ningu\u00e9m usa um dialeto do PostgreSQL em um banco MySQL. Ainda podemos eliminar trabalho na \u00e1rea de persistencia.<\/p>\n
Vamos pensar agora na camada de vis\u00e3o da aplica\u00e7\u00e3o, considerando que o usu\u00e1rio do sistema o utilizar\u00e1 atrav\u00e9s de um browser lendo HTML e conversando HTTP. A base que temos \u00e9: um servlet receber\u00e1 os par\u00e2metros e dever\u00e1 montar alguma resposta com base na requisi\u00e7\u00e3o. Utilizando o Spring MVC, elevamos essa base para algo mais interessante, com a possibilidade de mapear os par\u00e2metros recebidos em objetos e redirecionar a requisi\u00e7\u00e3o para um template que ir\u00e1 montar a resposta. A camada de controle, deve estar alinhada com a camada de vis\u00e3o pois o que a vis\u00e3o renderizar ser\u00e1 a causa de uma nova requisi\u00e7\u00e3o, logo os par\u00e2metros dessa nova requisi\u00e7\u00e3o devem condizer com que o controle espera. Quando desenvolvemos aplica\u00e7\u00f5es JEE a camada de vis\u00e3o \u00e9 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\u00e3o s\u00e3o completas.<\/p>\n
Quando vamos montar um HTML temos alguns problemas b\u00e1sicos a enfrentar. O primeiro \u00e9 que precisamos navegar em objetos e seus atributos para recuperar o modelo que ser\u00e1 utilizado na renderiza\u00e7\u00e3o. Ou seja, precisamos recuperar o valor do atributo nome<\/em> do objeto que est\u00e1 no escopo de requisi\u00e7\u00e3o com o nome pessoa<\/em>.<\/p>\n Depois que navegamos nos objetos dispon\u00edveis e escolhemos os atributos a serem mostrados, temos que escolher se mostramos esse valor como output, ou seja, apenas para leitura do usu\u00e1rio. Ou, como input, o usu\u00e1rio ir\u00e1 preencher esse valor, que deve ser lido pelo controle posteriormente. Nesse caso j\u00e1 vemos que o controle deve estar alinhado com a camada de vis\u00e3o.<\/p>\n As informa\u00e7\u00f5es mostradas no HTML n\u00e3o podem ficar soltas, precisamos de algumas tags como DIVs ou TABLEs para organizar o conte\u00fado na p\u00e1gina.<\/p>\n E finalmente precisamos ter algum meio de navega\u00e7\u00e3o, onde podemos criar formas de o usu\u00e1rio acessar as v\u00e1rias funcionalidades de um sistema.<\/p>\n De todos esses problemas que est\u00e3o presentes na montagem de um JSP, o \u00fanico que as tags do Spring implementa de forma que auxilia o desenvolvedor \u00e9 a navega\u00e7\u00e3o entre os objetos. No ambito de escolher entre input, output, organizar as informa\u00e7\u00f5es no HTML e ainda dar estilo, o Spring MVC n\u00e3o consegue auxiliar tanto. Por isso o Spring MVC n\u00e3o \u00e9 t\u00e3o produtivo para a camada MVC da sua aplica\u00e7\u00e3o. Mas ainda assim \u00e9 melhor que um servlet puro.<\/p>\n Com base nesses problemas levantados, vemos que ainda restam v\u00e1rias brechas que os frameworks de mercado n\u00e3o resolvem, e talvez nem esteja no escopo deles resolver. \u00c9 justamente nessas brechas que o Framework Next atua. Os problemas citados nesse artigo s\u00e3o resolvidos pelo Next de forma que o desenvolvedor n\u00e3o precise se preocupar com eles. Para configurar o Next com o Hibernate, e todos os objetos do Spring que d\u00e3o suporte ao Hibernate por exemplo, basta um arquivo connection.properties que cont\u00e9m apenas a url, driver, usu\u00e1rio e senha do banco de dados. Todas as outras configura\u00e7\u00f5es s\u00e3o feitas pelo Next, voc\u00ea s\u00f3 precisar\u00e1 modific\u00e1-las caso necessite. Na camada de vis\u00e3o o Next tem um grupo de tags para trabalhar com cada um dos problemas citados. Como os problemas est\u00e3o separados em cada grupo, um n\u00famero pequeno de tags consegue resolver a maior parte dos problemas. O Next tamb\u00e9m melhora a camada de controle com mais suporte e integra\u00e7\u00e3o com a camada de vis\u00e3o. E outras situa\u00e7\u00f5es que n\u00e3o falamos aqui, como autoriza\u00e7\u00e3o e autentica\u00e7\u00e3o, upload de arquivos, AJAX, relat\u00f3rios e casos de uso que s\u00e3o padr\u00e3o como CRUDs tamb\u00e9m s\u00e3o tratados pelo Next.<\/p>\n Vemos que o Next n\u00e3o tenta reinventar a roda, ele utiliza ao m\u00e1ximo os frameworks de suporte e vai al\u00e9m, provendo uma plataforma de mais alto n\u00edvel para dar mais produtividade ao desenvolvimento de aplica\u00e7\u00f5es JEE.<\/p>\n","protected":false},"excerpt":{"rendered":" No desenvolvimento de aplica\u00e7\u00f5es JEE, geralmente temos basicamente os seguintes artefatos: um banco de dados, classes e arquivos de templates que s\u00e3o os JSPs. Os banco de dados s\u00e3o relacionais, diferente da natureza orientada a objetos das classes que dispomos. Temos ent\u00e3o o primeiro problema: fazer a comunica\u00e7\u00e3o entre os objetos e o banco […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22],"tags":[24,27,21,26,25,9,28,29,23],"class_list":["post-355","post","type-post","status-publish","format-standard","hentry","category-artigo","tag-arquitetura","tag-framework","tag-hibernate","tag-java","tag-jee","tag-next","tag-problema","tag-solucao","tag-spring"],"_links":{"self":[{"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/posts\/355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/comments?post=355"}],"version-history":[{"count":3,"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/posts\/355\/revisions"}],"predecessor-version":[{"id":444,"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/posts\/355\/revisions\/444"}],"wp:attachment":[{"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/media?parent=355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/categories?post=355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nextframework.org\/site\/wp-json\/wp\/v2\/tags?post=355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}