Ocena:
Książka jest kompleksowym przewodnikiem po frameworku Grails, oferującym dokładne wyjaśnienia jego integracji ze Spring i omawiającym kluczowe funkcje Grails. Choć stanowi ona przydatne źródło informacji dla doświadczonych programistów Java, zakłada ona wcześniejszą wiedzę, która może być niedostępna dla mniej doświadczonych programistów. Użytkownicy doceniają dogłębne omówienie tematu, choć niektórzy krytykują przestarzałe odniesienia i niespójne przykłady.
Zalety:⬤ Kompleksowe omówienie funkcji Grails i integracji ze Spring.
⬤ Szczegółowe wyjaśnienia, które ułatwiają zrozumienie tematu.
⬤ Dobrze skonstruowana z logicznymi przykładami.
⬤ Przydatna dla doświadczonych programistów chcących pogłębić swoją wiedzę.
⬤ Napisany przez uznanych autorów w społeczności Grails.
⬤ Zakłada wcześniejszą znajomość języka Java i programowania obiektowego, przez co jest mniej przystępna dla początkujących.
⬤ Niektóre treści są przestarzałe, w szczególności odniesienia do wersji Grails
⬤ Krytyka dotycząca kwestii wydajności związanych z Groovy.
⬤ Niektóre rozdziały mogłyby być bardziej szczegółowe w obszarach takich jak GORM.
⬤ Przykłady nie zawsze działają zgodnie z opisem, co prowadzi do nieporozumień.
(na podstawie 16 opinii czytelników)
The Definitive Guide to Grails
Pod koniec lat 90. pracowałem nad projektem rozwijającym wielkoskalowe korporacyjne systemy zarządzania nauczaniem przy użyciu wczesnych technologii J2EE, takich jak EJB 1.0 i framework Servlet.
Maszyna szumu Java była w pełnym rozkwicie, a odniesienia do „EJB to i Java to” znajdowały się na okładce każdej większej publikacji IT. Mimo że to, co robiliśmy - i uczyliśmy się w miarę, jak to robiliśmy - wydawało się tak okropnie złe, branża wciąż powtarzała nam, że robimy dobrze. EJB miało rozwiązać wszystkie nasze problemy, a serwlety (nawet bez technologii widoku w tamtym czasie) były właściwym rozwiązaniem.
Ależ czasy się zmieniły. Obecnie Java i J2EE to dawno zapomniane hasła, a machina szumu rzuca w nas innymi skomplikowanymi akronimami, takimi jak SOA i ESB.
Z mojego doświadczenia wynika, że programiści nieustannie dążą do pisania mniejszej ilości kodu. Monolityczne specyfikacje J2EE, takie jak te przyjęte przez społeczność programistów na początku, nie pomogły.
Jeśli framework lub specyfikacja jest zbyt złożona i wymaga napisania mnóstwa powtarzalnego kodu, powinno to być natychmiastową czerwoną flagą. Dlaczego musieliśmy pisać tyle powtarzalnego kodu? Z pewnością istniał lepszy sposób.