Evaluare:
Cartea este un ghid cuprinzător al cadrului Grails, oferind explicații detaliate ale integrării sale cu Spring și acoperind caracteristicile cheie ale Grails. Deși servește ca o resursă utilă pentru dezvoltatorii Java experimentați, presupune cunoștințe anterioare care ar putea să nu fie accesibile programatorilor mai puțin experimentați. Utilizatorii apreciază acoperirea aprofundată, deși unii critică referințele învechite și exemplele inconsistente.
Avantaje:⬤ Acoperire cuprinzătoare a caracteristicilor Grails și a integrării cu Spring.
⬤ Explicații detaliate care îmbunătățesc înțelegerea.
⬤ Bine structurată, cu exemple logice.
⬤ Utile pentru programatorii experimentați care doresc să-și aprofundeze cunoștințele.
⬤ Scris de autori consacrați în comunitatea Grails.
⬤ Presupune cunoștințe prealabile de Java și programare orientată pe obiecte, ceea ce îl face mai puțin accesibil pentru începători.
⬤ Unele conținuturi sunt învechite, în special referințele la versiunea Grails
⬤ Critici privind problemele de performanță legate de Groovy.
⬤ Anumite capitole ar putea oferi mai multă profunzime în domenii precum GORM.
⬤ Este posibil ca exemplele să nu funcționeze întotdeauna așa cum sunt descrise, ducând la confuzie.
(pe baza a 16 recenzii ale cititorilor)
La sfârșitul anilor '90, lucram la un proiect de dezvoltare a unor sisteme de gestionare a învățării la scară largă, folosind primele tehnologii J2EE, cum ar fi EJB 1.0 și cadrul Servlet. Mașina de promovare a Java era în plină desfășurare, iar referirile la „EJB asta și Java asta” erau pe coperta fiecărei publicații IT importante.
Chiar dacă ceea ce făceam - și învățam pe măsură ce o făceam - ni se părea îngrozitor de greșit, industria continua să ne spună că facem ceea ce trebuie. EJB urma să ne rezolve toate problemele, iar servlet-urile (chiar și fără o tehnologie de vizualizare la acel moment) erau lucrul corect de utilizat. Vai, cum s-au schimbat vremurile.
În zilele noastre, Java și J2EE sunt cuvinte la modă de mult uitate, iar mașinăria de publicitate ne aruncă alte acronime complexe, cum ar fi SOA și ESB. Din experiența mea, dezvoltatorii sunt într-o misiune continuă de a scrie mai puțin cod.
Specificațiile J2EE monolitice, precum cele adoptate de comunitatea de dezvoltatori în primele zile, nu au ajutat. Dacă un cadru sau o specificație este excesiv de complexă și vă cere să scrieți o grămadă de cod repetitiv, ar trebui să fie imediat un mare semnal de alarmă.
De ce a trebuit să scriem atât de mult cod repetitiv de tip boilerplate? Cu siguranță exista o cale mai bună.
© Book1 Group - toate drepturile rezervate.
Conținutul acestui site nu poate fi copiat sau utilizat, nici parțial, nici integral, fără permisiunea scrisă a proprietarului.
Ultima modificare: 2024.11.08 07:02 (GMT)