joi, noiembrie 08, 2012

GRAILS - the search is over?



Dupa cum arata acest radar recent de tehnologii care se opreste asupra framework-urilor Web se pare ca Spring MVC, Play si Grails sunt printre castigatori. Daca Spring MVC e de asteptat, GRAILS si Play sunt surprize. In continuare o sa vorbesc despre experienta cu GRAILS din ultima jumatate de an. Cred ca daca Spring este tinta ta, cu GRAILS atunci the search is over. Dar in rest, pentru cealalta jumatate fara Spring (in fapt JEE clasic se bazeaza pe EJB-urile moderne de la 3.0 in sus in care exista deja dependency injection, etc - eu prezic ca intre Spring si EJB piata este jumatate/jumatate) inca cred ca the search is never over. De fapt nu stiu cine e de fapt invingatorul, GRAILS sau Spring!

Interesant in GRAILS


  • Este mai mult decat un framework web (are si parte de middleware: Spring; si persistenta:Hibernate); poate fi numit mai mult un starter de aplicatii (ca Roo, Seam)
  • Este un concurrent pentru Play (bazat pe Java, Scala, Akka, add-ons) - de remarcat ca initial Play pornise tot cu Groovy dar a renuntat in favoarea Scala
  • Sistem pluginabil (in dev time si nu in runtime) dar functional; in general pluginurile sunt infasurari de alte librarii dar adauga constructii specifice Grails (servicii, controlere, tag-uri) care usureaza folosirea lor (e ceva in plus decat simpla lor aducere ca in proiectele cu Maven sau Ivy – dependency management); pluginurile sunt de fapt miniaplicatii Grails impachetate; repository de plugin-uri destul de activ
  • Setat implicit sa creeze schema din entintitati (bazat pe Hibernate); induce astfel un mod de lucru aplecat spre POO si nu spre schema de date (nu se genereaza entitati din schema ca de obicei)
  • Un set clar si fix de stereotypes - archetypes API in denumirea lor (controller, view, serviciu, tag, entitate, command object, etc) toate legate prin injectie folosind default configuration
  • Bazat pe Spring pentru dependency injection (posibilitatea de a face injectare si de beanuri clare de Spring prin xml-uri)
  • Spring via un set de plugin-uri bine definite si intretinute cu grija poate aduce: securitare, accces la retele sociale, acces la baze de date nerelationale, caching, etc (se poate spune ca Grails isi trage seva din Spring)
  • Usurinta in a scrie propriile taguri (mult mai simplu decat in JSP)

Inside GRAILS


  • Librariile externe sunt aduse cu IVY (din cauza ca se foloseste (G)Ant – eventual din repo-uri de Maven)
  • Build inclus – un set de target-uri de ant (Gant = un DSL Groovy echivalent pentru Ant) care pot fi extinse cu propriile scripturi (sau cu scripturi aduse de plugin-uri)
  • Persistenta cu GORM o abstractizare peste Hibernate (sau mai sigur peste Spring Data); ofera transparenta fata de storage – poate fi folosit si peste baze  de date nerelationale
  • Sitemesh deja integrat in aplicatie (layout-uri usor de facut pentru pagini - macro compozitie)
  • Partial template-uri care permit refolosirea de fragmente in pagini (populate cu modele – micro compozitie)
  • Set implicit de tag-uri (tot ce are JSTL si mai mult)
  • Scafolding static si mai ales dinamic (plecand de la entitati) printr-un set de template-uri care la nevoie pot fi modificate spre a genera codul dorit de dezvoltator
  • Configurarea apliatiei cu DSL-uri de Groovy (mult mai usor de accesat programmatic decat XML-urile clasice dar nu decat cu adnotari)
  • Vine implicit cu plugin de tomcat si de hibernate (ele dau versiune distributiei)
  • Suport pentru testare unitara, integrare, functionala (mock-ing dat de framework de orice)
  • URL rewrite inside (nu e nevoie sa se foloseasca alte librarii cu  filtre externe)
  • Populare de date la bootstrap inside (nu e nevoie de scripturi de initializare)
  • Plugin de resources inside by default instalat (nu e nevoie de librarie externa pentru compilare Less, CDN, minimizare, concatenare de resurse:js-uri, css-uri, etc)
  • Un alt scop numit flash – 2 requesturi consecutive
  • Suport de ajax prin tag-uri care infasoara framework-uri JS la alegere (JQuery, etc)
  • GSP pentru view-uri – se foloseste groovy drept expression language
  • Suport pentru scriere de documentatie inside – eport spre PDF, Html
  • Multe g-uri: GSP, GANT, GORM, Groovy, Grails
  • Closures aduse de groovy

Pro GRAILS


  • Hot deploy sau mai bine zis instant reload of classes din cauza naturii dinamice pe care o are Groovy (inclusive in fisierele de proprietati – nu e nevoie de publish via IDE sau tool-uri ca JRebel)
  • Sintaxa redusa (Syntactic Sugar) – groovy e scripting
  • Suport integrat pentru environmente la nivel de aplicatie (ca in Spring)
  • Se poate intercala si cod scris in Java (.groovy-urile se duc tot spre bytecode Java in JVM, groovy este comptibil cu Java – sper ca 100%)
  • Productiv in dezvoltare

Contra GRAILS


  • Slab tipizat (si no compile checking) deci foarte multe probleme se vad doar in runtime (inclusiv typos cum ar fi un nume gresit de metoda care nu este definita si care este totusi apelata)
  • Bazat pe Groovy – limbaj de scripting care nu incurajeaza clean code si o sintaxa ingrijita (de fapt Groovy este foarte relaxat in privinta sintaxei fata de Java care este mai restrictiv; prin definirea de DSL-uri Groovy poate oferi o sintaxa superioara mai apropiata de limbajul natural)
  • Nu functioneaza modificatorii de acces in Groovy - poti executa o metoda chiar daca este private (defavorizeaza incapsularea si ideea de API expus (a la Java))
  • In Groovy nu sunt luate in calcul checked exceptions (deci nu se poate face distinctie intre exceptii de business si exceptii de sistem)
  • Suport defectuos in Eclipse (STS, GST) dar mai bun in IntelijIdea (nu perfect)
  • Nu are validare client side by default (generate from the server side ca in Struts 2)
  • MVC-ul este request/response nu component based (a la JSF) si deci oarecum mai putin productiv
  • Depinde de Groovy (nici o idee despre support – am avut de cateva ori impresia ca unele lucruri nu functioneaza cum m-am astepta) – deci putin probabil sa fie adoptat de firmele mari (care prefera dependenta de JDK-ul de Java mai stabil)
  • Din cauza ca Groovy este limbaj dynamic (multe lucruri se intampla In runtime) este de 2 pana la 4 ori mai lent decat Java (ca infasoara si alte librarii poate sa aduca un alt overtime)