{"id":8,"date":"2010-03-14T16:13:02","date_gmt":"2010-03-14T19:13:02","guid":{"rendered":"http:\/\/www.javaframework.org\/portal\/2010\/03\/14\/playframework-review\/"},"modified":"2010-03-14T16:31:19","modified_gmt":"2010-03-14T19:31:19","slug":"playframework-review","status":"publish","type":"post","link":"https:\/\/www.javaframework.org\/portal\/2010\/03\/14\/playframework-review\/","title":{"rendered":"PlayFramework Review"},"content":{"rendered":"

A pouco tempo fiquei conhecendo um novo framework para Java de alta produtividade, trata-se do PlayFramework http:\/\/www.playframework.org<\/a>. A sua primeira vers\u00e3o est\u00e1vel foi disponibilizada em Fevereiro de 2008, e hoje se encontra na vers\u00e3o 1.0.1. Achei o framework interessante e resolvi escrever esse review.<\/p>\n

<\/p>\n

Para testar o framework, fiz o tutorial do site que mostra como construir um blog. Foi bastante tranquilo, n\u00e3o deu erros inesperados e o tutorial estava bastante condizente com a constru\u00e7\u00e3o da aplica\u00e7\u00e3o. Utilizei o eclipse para construir o projeto. O play vem com uma ferramenta que permite adaptar o projeto a v\u00e1rias IDEs de forma bem f\u00e1cil.
A primeira coisa a se notar \u00e9 que o play \u00e9 um framework Java. Mas n\u00e3o \u00e9 um framework JEE. Eu n\u00e3o vejo problema nisso a principio, mas ao inv\u00e9s de manter s\u00f3 o framework, o desenvolvedor do play, ter\u00e1 que manter tamb\u00e9m, uma arquitetura, um servidor, etc. Ainda n\u00e3o sei o que ele usa por baixo dos panos, mas seria bem viavel se utilizasse algo como um Tomcat turbinado.
Eu acho que o JEE hoje, com a utiliza\u00e7\u00e3o de frameworks n\u00e3o tem tanta import\u00e2ncia na arquitetura da aplica\u00e7\u00e3o, a n\u00e3o ser para criar um request e response, e fazer a comunica\u00e7\u00e3o HTTP. No caso do JSF, por exemplo, request e response praticamente nem existem. O JEE, mesmo com as \u00faltimas vers\u00f5es, n\u00e3o oferece grande vantagem j\u00e1 que voce usar\u00e1 um framework por cima. At\u00e9 mesmo o JSP est\u00e1 saindo de linha<\/i>. E isso se deve ao fato de suas limita\u00e7\u00f5es. O pessoal acaba deixando de lado os recursos do JEE e criando o pr\u00f3prio engine.
Um outro aspecto, que faz grande parte das m\u00e1gicas<\/em>, que permitem ao play ser bastante produtivo \u00e9 a utiliza\u00e7\u00e3o de um Java Agent. Esse java agent, apesar de eu n\u00e3o ter estudado a fundo, deve "tunar" as suas classes em tempo de execu\u00e7\u00e3o. Fazendo os getters e setters que voc\u00ea n\u00e3o escreveu, implementando os m\u00e9todos do Model e fazendo o Hot Deploy do seu projeto sem a necessidade de reiniciar o servidor. Um Class Loader especial provavelmente ajuda nesse processo tamb\u00e9m.
Hoje a maioria dos frameworks utilizam a manipula\u00e7\u00e3o de byte codes para facilitar o desenvolvimento. Essa manipula\u00e7\u00e3o permite que sejam feitas algumas coisas pelo usu\u00e1rio, que, na verdade, \u00e9 a tarefa do framework. Antes da prolifera\u00e7\u00e3o dessa t\u00e9cnica o que acontecia, \u00e9 que o framework elevava a aplica\u00e7\u00e3o a um n\u00edvel de abstra\u00e7\u00e3o bem mais alto para poder trabalhar numa cama intermedi\u00e1ria entre a JVM e a aplica\u00e7\u00e3o. Hoje os frameworks atuam entre o bytecode e a JVM, mantendo a camada de aplica\u00e7\u00e3o sobre o Java puro, ao inv\u00e9s de sobre uma camada do framework. Isso facilita bem o desenvolvimento e o aprendizado das ferramentas.
O esquema de redirecionamento tamb\u00e9m \u00e9 bastante interessante. Quando voc\u00ea faz por exemplo:<\/p>\n

GET     \/posts\/{id}                             Application.show  <\/p>\n

O framework permite que acesse um post com a URL \/posts\/6, utilizando conceitos RestFull. Mas vai al\u00e9m disso, se voc\u00ea utilizar no seu c\u00f3digo um redirecionamento como:<\/p>\n

@{Application.show(post.id)}  <\/p>\n

O framework ir\u00e1 ver que Application.show tem um route, e vai renderizar o link como \/posts\/${post.id}. Ou seja, faz a leitura ao contr\u00e1rio tamb\u00e9m. Isso eu achei bem legal.
A configura\u00e7\u00e3o do framework \u00e9 atrav\u00e9s de arquivos de properties, que por sinal s\u00e3o bem completos. Esses arquivos s\u00e3o documentados e voc\u00ea quase n\u00e3o tem que escrever neles, j\u00e1 vem tudo pronto praticamente. Se quiser alguma configura\u00e7\u00e3o ou funcionalidade apenas descomente alguma linha do arquivo.
A linguagem utilizada nos templates tem bastante poder, e utiliza groovy para fazer o evaluation. Oferece uma sintaxe especial para diversos tipos de funcionalidade: # para chamar scripts ou tags, @ para links, etc. Isso torna a leitura do c\u00f3digo f\u00e1cil depois que voce acostuma com os s\u00edmbolos. O sistema de includes das p\u00e1ginas tamb\u00e9m \u00e9 legal, pois permite que sejam utilizados templates dentro de templates.
Os controllers s\u00e3o bastante simples de se escrever, sem segredo. E oferece um esquema de valida\u00e7\u00e3o e mensagens, igualmente simples.
O framework tem uma caracter\u00edstica de ser Stateless. Ou seja, voc\u00ea n\u00e3o deve guardar estado nos objetos. \u00c9 uma arquitetura v\u00e1lida, n\u00e3o \u00e9 necess\u00e1rio voce ter milhoes de objetos cada um num escopo diferente para ter uma aplica\u00e7\u00e3o robusta e bem implementada. Essa variedade de escopos usadas em alguns frameworks, acaba inclusive causando alguns problemas.
Uma outra feature que estudarei mais profundamente e me interessou, \u00e9 que a sess\u00e3o \u00e9 gravada em cookies. Isso pode ser uma grande vantagem do framework. J\u00e1 que n\u00e3o \u00e9 utilizada mem\u00f3ria do servidor, a aplica\u00e7\u00e3o pode escalar melhor.
A ferramenta parece ser bastante est\u00e1vel. N\u00e3o apresentou erros durante o desenvolvimento. O tutorial \u00e9 bem explicado, e tem boa documenta\u00e7\u00e3o.
Vamos dizer assim que \u00e9 um framework bem redondo.<\/p>\n

Algumas cr\u00edticas:<\/b>
Natureza static: Apesar de concordar com a natureza stateless, n\u00e3o concordo muito com a natureza static. Nos controllers os m\u00e9todos s\u00e3o todos static e parece que a ideia \u00e9 trabalhar assim no framework, acho que \u00e9 uma desvantagem bem grande, e deve ser revisto.
View: A linguagem utilizada em templates \u00e9 bastante poderosa, mas as views s\u00e3o escritas praticamente com HTML. E as tags tamb\u00e9m s\u00e3o assim. \u00c9 como se voce tivesse tag files do JSP, mas n\u00e3o tenha tags mesmo, escritas em Java.
Sobrescreve o JEE: O play \u00e9 tudo: framework, servidor, ferramenta. Isso vai tornar mais complicada a ado\u00e7\u00e3o e tamb\u00e9m a evolu\u00e7\u00e3o do mesmo, j\u00e1 que tem muito c\u00f3digo a ser visto. O pacote do play tem 45 Mb. \u00c9 muita coisa, \u00e9 claro que por baixo dos panos foram utilizadas outras ferramentas. Mas como a integra\u00e7\u00e3o \u00e9 feita pelo play, esse c\u00f3digo tem que ser mantido por ele.<\/p>\n

Considera\u00e7\u00f5es finais:<\/b>
O Play parece funcionar realmente, foi bastante est\u00e1vel nos testes feitos. O sistema de deploy \u00e9 excelente. \u00c9 produtivo e f\u00e1cil. Apesar de ter todas essas vantagens, e que ele est\u00e1 seguindo a tend\u00eancia, praticamente todo o framework pode ser substitu\u00eddo por ferramentas que existem no mercado. A grande vantagem do play \u00e9 que j\u00e1 vem tudo pronto e configurado.
Para ter um framework igual ao play, voc\u00ea pode utilizar por exemplo o Spring. No controller utiliza algo como VRaptor<\/a> ou Next<\/a>, que s\u00e3o baseados no Spring MVC<\/a>. Orienta\u00e7\u00e3o a aspectos, para fazer os m\u00e9todos que n\u00e3o s\u00e3o implementados por voc\u00ea como os getters, setters e m\u00e9todos do Model. E utilizar um template mais poderoso do que o JSP. As queries j\u00e1 s\u00e3o contruidas com JPA mesmo. A\u00ed voc\u00ea j\u00e1 tem um play. Com alguma configura\u00e7\u00e3o de class loader e java agent, voc\u00ea consegue o mesmo deploy. A diferen\u00e7a \u00e9 que nesse caso voc\u00ea estar\u00e1 no Standard, ou seja, usando tomcat, eclipse, plugins, tudo que todo mundo j\u00e1 utiliza. Ao inv\u00e9s de jogar tudo fora e come\u00e7ar do zero.
N\u00e3o estou criticando o framework e falando que ele \u00e9 ruim por causa disso. Pelo contr\u00e1rio, acho que ele fez tudo certo, utilizando tendencias de mercado e tudo mais. S\u00f3 que voc\u00ea come\u00e7a de uma plataforma nova e isso dificulta bastante a ado\u00e7\u00e3o.
Apesar tudo que tem no play, existir no mercado, existe uma grande vantagem do play. Ele j\u00e1 est\u00e1 todo configurado e funcionando, as interfaces j\u00e1 foram testadas e est\u00e3o est\u00e1veis. E n\u00e3o \u00e9 f\u00e1cil montar uma arquitetura dessa, gasta muito tempo, testes e c\u00f3digo. E n\u00e3o \u00e9 qualquer programador que consiga fazer isso.
A minha cr\u00edtica em rela\u00e7\u00e3o ao play \u00e9 que ele poderia utilizar algumas ferramentas que j\u00e1 existem, mesmo que existam limita\u00e7\u00f5es, com um pouco de raciocinio, poderia ser feito algo muito semelhante sen\u00e3o igual ao que o play \u00e9 hoje. E esse \u00e9 o grande desafio de se desenvolver frameworks, partindo do que j\u00e1 existe, como podemos melhorar? Fazer tudo de novo, \u00e9 claro que teremos algo melhor. Fazer melhor com a base instalada que \u00e9 o dif\u00edcil. Ent\u00e3o vejo o play mais como uma proposta de como fazer, do que realmente adot\u00e1-lo em larga escala.
Utilizaria o play em algum projeto? Sim.
Mudaria alguma coisa nele? Sim, faria uma camada facilitadora do que j\u00e1 existe, e j\u00e1 configurada, ao inv\u00e9s de criar tudo do zero. Assim a ado\u00e7\u00e3o poderia sem bem maior.
No mais, gostei da ferramenta, e vou estudar alguns aspectos mais profundamente. Achei bastante v\u00e1lida a iniciativa.<\/p>\n","protected":false},"excerpt":{"rendered":"

A pouco tempo fiquei conhecendo um novo framework para Java de alta produtividade, trata-se do PlayFramework http:\/\/www.playframework.org. A sua primeira vers\u00e3o est\u00e1vel foi disponibilizada em Fevereiro de 2008, e hoje se encontra na vers\u00e3o 1.0.1. Achei o framework interessante e resolvi escrever esse review.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[4,6,7,5],"class_list":["post-8","post","type-post","status-publish","format-standard","hentry","category-reviews","tag-framework","tag-jee","tag-produtividade","tag-web"],"_links":{"self":[{"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/posts\/8","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":2,"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"predecessor-version":[{"id":11,"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/posts\/8\/revisions\/11"}],"wp:attachment":[{"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.javaframework.org\/portal\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}