1. Spring, Hibernate and more, while doing less
Gavin Hogan – Software Architect, CommerceHub

2. A little bit about me.
• Software Architect at CommerceHub
• Working with Java and Groovy for 8 years
• Working with Grails for 3 years

3. • Grails in a nutshell
• Some Grails patterns and philosophy
• Spring in Grails
• Object Persistence
• Grails web technologies
• Grails plugin ecosystem
• A closer look at groovy
• Live demo
• Q&A

4. … and a little history
• Grails is a rapid web application development
framework
• Grails is a full stack framework, not simply a web
development framework
• Grails Leverages Groovy and Spring extensively
• Modular and extensible though the plugin
infrastructure

5. … and a little history
• Backed by SpringSource/VMWare
• Grails is mature, project started in 2005, current
version is 2.2
• Inspired by Ruby on Rails. An RoR influence remains,
but it is not a clone.

6. • Grails was inspired by RoR. Ease of development is a
primary objective
• Leverage convention over configuration with
sensible defaults
• Never eliminate flexibility or capability for the price
of simplicity
• All the power of Spring, Sitemesh, Hibernate is
available, but common use case are pre configured

7. • Leverage existing operational capacity and
expertise. 'Plain old java deployment’
• Portable war based deployment
• Apache Tomcat is the default container
• ‘Standing on the shoulders of Giants’, Java
compatibility allows the use of existing industrial
strength components.

8. • Grails really is ‘Spring in a can’
• Most grails applications do not have any Spring xml!
• Grails automates the configuration and 'wiring' of
Spring beans
• Name based ‘convention over configuration’
• UserService.groovy will automatically generate a
bean named ‘userService’
• Object fields are autowired by name

9. • Plugins and applications can interact with Spring
lifecyles.
• Controller layer is a wrapper around Spring MVC.
• Spring extensions and subprojects are easy to
include with plugins.
• Spring Security
• Spring Integration
• Spring Batch
• …

10. • Plugins and applications can interact with Spring
lifecyles.
• Controller layer is a wrapper around Spring MVC.
• Spring extensions and subprojects are easy to
include with plugins.
• Spring Security
• Spring Integration
• Spring Batch
• …

11. • Grails Object Relationship Mapping (GORM) is the
default persistence layer in a Grails application
• The default GORM implementation is a wrapper
around Hibernate.
• Alternative implementations for
MongoDB, Reddis, REST, SimpleDB and Riak exist
• Mapping is sensible by default.
• Class names name to table names
• Field names map to column names

12. • Dynamic finders methods are automatically added
to your objects at run time
• E.g. User.findAllByLastName('Hogan') will return
a list of users objects with that last name
• The finders support composite queries and are very
capable. Criteria builders and named queries support
more challenging requirements
• Mapping DSL, gives easy access to common
configurations for Hibernate persistence

13. • Controllers and controller actions are automatically
mapped to urls based on name
• UserController.list() is mapped to user/list/
• HTTP paramaters are automaticaly bound to
controller arguments
• UserController.show(String id) is mapped to
user/show/<id>

14. • Binding transparently applies to objects used as
arguments in controller actions.
• UserController.update(User u) is mapped to
<appName>/user/update/<id>?firstName=<firstN
ame>&lastName=<lastName>
• Generally speaking you do not think about binding
much when working with Grails

15. Validation
• Grails provides simple validation DSL for Domain
and Command objects.
• Common validation constraints built in
• Unique
• Size
• Email
• Not Blank/Null
• Custom constraints easy to add directly to objects

16. Validation
• Validation failures generate errors, which are
automatically associated with i18n message codes
• Validation is intended for domain and command
objects but can be assigned to POJOs too.
• Grails validation is powerful, but does not provide a
good business rules capability.

17. Views
• The default view technology for grails is 'Groovy
Server Pages' (GSP)
• Very similar to JSP, fewer rough edges.
• Views are automatically associated with actions
based upon name
• UserContoller.list() assumes a list.gsp in /views/user/
• Templating is extremely easy, leverages Sitemesh.

18. Taglibs
• I swore to never use taglibs many years ago, Grails
makes taglibs a joy
• They are simple reusable view components.
• Taglibs a written as regular groovy Closures, they
can interplay with each other and the rest of the
application code
• To create a taglib, simply create a class with ‘TagLib’
at the end of its name, all public closures will
automatically become tags

19. What makes them better that jar files?
• Plugins are core to Grails. Grails itself is built as a
collection of distinct plugins
• In Grails, plugins are the standard unit of reusable
code.
• Plugins usually package behavior, not only
capability.
• E.g. Including the Shiro security plugin actually
secures/locks down your application.

20. What makes them better that jar files?
• Anyone can write a plugin. You can choose to share
a plugin on grails.org
• The range of plugins is now vast
• Though quality is varied
• Suffers from the GitHub effect, “I can share this
so I will!”

21. • Not yet…
• Lets talk about Groovy

22. • Groovy is a dynamic JVM language
• It compiles to java bytecode and runs in the same
jvm as Java code
• Intended to be familiar/comfortable to Java
developers
• Groovy provides additional, powerful programing
features, Closures, Mixins, Meta-Programming

23. Sensible simplifications
• Closures can be thought of as being similar to
functions in JavaScript. You can pass them or call
them.
• Mixins are used to compose complex object
without inheritance. You may think of them as
behavioral interfaces, that actually do stuff.

24. Sensible simplifications
• Meta-programming allows developers to modify
the behavior of a class at compile-time or
runtime. Grails extensively uses meta
programming to add behavior to your application
• Groovy is not strongly typed, ‘def’ is similar to
‘var’ in JavaScript, and can be thought of as
similar to Object in java.
• Some many enhancements to Collections API

25. Because live coding always works as expected!

27. @gavinInNY
gavinhogan@gmail.com