ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 7
Abonament PDF

Liferay Service Builder vs. Spring Roo

Vlad Hosu
Senior Developer
@ISDC



DIVERSE

R.A.D. sau Rapid Application Development este un numitor comun în ziua de azi atunci când vorbim despre metodologii de development. Pe scurt, această metodologie presupune adunarea de cerințe funcționale și non-funcționale prin workshop-uri sau metode de comunicare cât mai rapide, prototipizare și reutilizabilitatea componentelor implementate. Pentru a îndeplini cu succes această metodologie în ceea ce privește timpul de dezvoltare al aplicațiilor, multe companii folosesc unelte pentru generare de cod. Conceptul de Vendor Lock-in este menit să atragă atenția asupra deciziilor tehnice vis-a-vis de ușurința cu care putem integra un generator de cod în tehnologia pe care o folosim dar și dificultatea cu care putem customiza sau chiar elimina anumite componente generate. Este o practică extrem de comună; așa face Oracle, așa face IBM, așa face Apple, pe scurt, așa fac toți.

Pentru a detalia acest concept am ales un studiu de caz: Spring Roo vs Liferay Service Builder. Amândouă sunt unelte pentru generare de cod, amândouă sunt compatibile cu Liferay. Din acest punct de vedere voi face un DAR (Decision Analysis and Resolution).

Pentru această analiză vor fi folosite următoarele criterii:

  • Meta date: capacitatea de customizare a codului generat prin descriptori
  • Calitatea codului generat: cu respect la standarde de codare, ex. Oracle Code Conventions (http://www.oracle.com/technetwork/java/codeconv-138413.html)
  • Documentație
  • Vendor Lock-out: cât de ușor vă scăpați de codul generat sau să-l integrați în aplicație
  • Compatibilitate: aspecte de integrare cu tehnologia Liferay

Meta date - Liferay Service Builder


Beneficiază de un plugin de Eclipse simplu și intuitiv pentru a rula unealta. O alta variantă este folosirea Ant sau Maven pentru rulare. Ea vă oferă un xml pentru configurare care, vă va genera pentru fiecare entitate câte un domain model, layer de persistență și de servicii. Totodată el va genera automat și metode de CRUD și metode utilitare pentru găsirea de entități dupa proprietățile acestora. Aceasta acoperă majoritatea straturile necesare, mai puțin cel de prezentare. În schimb, oferă integrare cu servicii web JSON si SOAP.


			 

PUBLIC "-//Liferay//DTD Service Builder 6.1.0//EN"
"http://www.liferay.com/dtd/liferay-service-builder_6_1_0.dtd">

Vlad Hosu
TSM
 














Atributul de package-path din tag-ul "service-bilder" este folosit pentru numele pachetului de bază al codului generat. Tag-ul "namespace" este folosit pentru denumirea tabelei în baza de date iar în cazul acesta va fi tsm_Articol. Atributele de "local-service" si "remote-service" de pe tag-ul "entity" sunt folosite pentru specificarea persistenței locale și respectiv, dacă doriți și generarea de servicii web JSON și SOAP. Specificarea tag-ului "finder" va genera API si Implementare pentru obținerea unei liste de Articole in funcție de câmpul "autor". Desigur se poate customiza mult mai mult.

Meta date - Spring Roo


Pentru a configura Spring Roo aveti nevoie de STS (un Eclipse pentru Spring), o altă variantă este să alegeți consola. Pentru consolă, va trebui sa definiti pentru fiecare task câte o comandă. Veți identifica multe taskuri repetitive care ar putea fi abstractizate. Din punctul meu de vedere configurarea nu este atât de vizuală, precum o diagrama sau un xml. Un aspect negativ este: la fiecare fișier .java generat, Roo mai adaugă și un fișier AspectJ, asta înseamnă de două ori mai multe fișiere, deci o mentenanță dificilă pentru customizarea anumitor componente. Un aspect foarte important este ca Roo poate genera si stratul de prezentare la domeniul definit. Un mare atu față de Liferay Service Builder.

Același exemplu, referitor la entiatea Articol se va putea genera cu Roo folosind urmatoarele comenzi și în plus vom avea stratul de web, test de integrare și Spring Security:

  • project --topLevelPackage ro.tsm
  • jpa setup -- provider HIBERNATE --database MySQL
  • entity jpa --class ~.domain.Articol --testAutomatically
  • field string --fieldName titlu --notNull
  • field string --fieldName descriere --notNull
  • field string --fieldName autor --notNull
  • field number --fieldName likeCount --type java.lang.Long
  • finder add --finderName findArticoleByAutor --class ~.domain.Articol
  • perform tests
  • perform eclipse
  • web mvc setup
  • web mvc all --package ~.web
  • security setup

Precum exmplicam anterior, dacă veți avea mai multe entități va trebui să repetați pentru fiecare dintre ele pașii referitori la definirea acestora. Comanda "perform tests" este pentru a testa integrarea entității generate in proiect. Comanda "perform eclipse" este pentru configurarea workspace-ului. Dacă aveți STS, nu mai este nevoie de rularea acestei comenzi. Altfel ea sau trebuie rulată sau este necesară instalarea unui plugin adițional pentru mavenizarea proiectului.

Calitatea Codului

Este important de menționat că acest atribut nu contează decât dacă veți avea nevoie să intrați in codul generat. Alfel, cel mai probabil sursele generate vor ajunge într-o librărie externă.

Calitatea Codului - Liferay Service Builder

Dacă punem un Sonar (vezi http://www.sonarsource.org/) pe el vom găsi la fiecare metodă câte un Major cel puțin. Spre exemplu:

• Prinderea de throwable in excepții


				} catch (Throwable t) {
			

• Castarea neverificată


			AdditionalInformationClp oldCplModel =
			     (AdditionalInformationClp) oldModel;
			

Modul in care se generează o entitate, este destul de complex și nu este conceput decât pentru a face parte dintr-un API (asta pentru a avea capacitatea de a suporta bazele de date majore ca și MSSQL, PostgreSQL, MySQL șamd). Aici nu includem si layer-ul de srvicii, care mai adauga in API înca opt clase: (http://www.liferay.com/community/wiki/-/wiki/Main/Service+Builder)

Calitatea Codului - Spring Roo

Oferă un cod care respectă best-pratice-urile impuse de Oracle si Google(pe partea de front-end)

Totodată, în orice moment aveți ocazia de a scoate o metodă din starea de cod generat în cod customizat ceea ce aduce un beneficiu destul de puternic.

Documentație - Liferay Service Builder

Beneficiază doar de o pagină de Wiki - documentație inexistentă. De altfel, veți putea găsi foarte multe informații legate de această unealta și pe forumuri. Liferay are o comunitate destul de mare și în creștere.

In cazul unui parteneriat cu Liferay beneficiați de tot suportul necesar pentru a folosi această unealtă.

Documentație - Spring Roo

Roo în schimb are parte de o documentație destul de bogată prin comparație. În ceea ce privește forumurile, comunitatea Roo este înca destul de restransă.

Vendor Lock-out - Liferay Service Builder

Trebuie rescris totul pentru a ajunge la un cod Java extensibil, utilizabil si ușor de întreținut dar având in vedere că Liferay generează API-ul detașat de implementare, oricând se poate scrie o altă implementare într-un alt plugin dar asta nu vă va ajuta niciodata la scoaterea codului generat. Pe scurt, Liferay Service Builder oferă un contract pentru servicii și pentru model iar asta este suficient în majoritatea cazurilor.

Vendor Lock-out - Spring Roo

Unealta poate translata tot ce este în fișierele AspectJ în cod Java. Asta oferă un grad de extensibilitate ridicat.

Compatibiliate

Este important de menționat că aspectele de integrare pot să vă ofere o pierdere de timp mai mare decăt beneficiul generatorului de cod în sine. Pe scurt, pot apărea probleme de prototipizare.

Totodată integrarea cu Spring este un pic diferită, anume container-ul de Spring este în Liferay și injecția de bean-uri se face într-un mod diferit din plugin. Asta presupune că veți avea de făcut o configurare suplimentară la Spring Roo pentru a-l putea folosi.

Concluzii

In concluzie, puteți să considerați folosirea Service Builder-ului atunci când nu se consideră partea de Vendor Lock-out, Calitatea Codului sau Documentația; asta presupune că nu vă puneți problema schimbării tehnologiei pe parcusul proiectului și aveți suficiente conușstințe vis-a-vis de acest tool. Pe de altă parte, Spring Roo vă oferă o satisfacție mai mare in ceea ce privește calitatea codului sau documentația dar veți avea si un risc, în funcție de prototipizarea aplicației.

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO