A year ago, I did my first official Grails project. Since it was a short term project, I felt I had to start with both feet in; working on the actual business requirements for the project immediately. Looking back at the project, that wasn’t the right decision. In reviewing the project, I came up with a checklist of what I would have done differently.
As I put this list together, most of it seems common sense to me now; a lot of this is true for anyone adopting a new technology stack for a project. While this can be applied to other technology stacks, my goal is to list out specifics with Grails. I’m sure my list is incomplete, and would love comments from others to add to this list.
Pick an IDE suited for Groovy and Grails
I used Eclipsed Based, Spring Tool Suite (STS), and I was heavily disappointed. The Groovy support was limited. I was also on a Mac OSX and you combine the slow file system of the Mac with STS and I spent more time waiting for the please wait cursor to go away, than actually develop code. Since I was on this project part-time, I thought I couldn’t justify getting IntelliJ; that was a mistake. Being very familiar with Eclipse for my Java development, the transition to STS was super easy, however, it didn’t really help me write Groovy/Grails applications to the level I was expecting. The limited auto-complete for Groovy and the slowness of the application was unbearable; big disappointment.
The more your IDE supports Groovy, the more you will write true Groovy Syntax. With STS I stayed with static typing as much as possible, so the IDE would be able to handle code completion and compile errors. With IntelliJ, I’m sure I would have embraced more dynamic typing.
Learn Groovy w/out Grails
Take at least 2 days and learn Groovy w/out Grails, GORM, or any other addition to the technology stack. Your first Groovy classes will end up being Java written in Groovy. You will most likely fail to take advantage of all the cool features of Groovy. I have used closures with all of my functionality programming experience, but I hadn’t used them in Groovy before; and it has been a while, since I spend most of my work day using Java. Your going to want to throw away your first code anyway, so pick a simple problem and write Groovy. I would take a complex algorithm you wrote in Java, that included nested classes, anonymous classes, reading and writing a markup language (HTML or XML) and rewrite it in Groovy. Making sure you take advantage of closures, native lists or maps, groovy markup, and dynamic typing.
Follow a Difference from Java article, such as codehaus, and work through an example hitting on these concepts. Be sure to include closures, native lists & maps, safe navigation, and dynamic typing. As many that use Groovy, you will soon wish a lot of these conventions were available in Java. Something as simple as safe navigation is such a simple concept that saves a lot of typing and makes code more readable. Again, take the time to learn Groovy, so you take advantage of writing good Groovy code. Since your initial code will look more like Java than Groovy, give yourself an assignment so you can throw the code away, when you are done. You will probably want to.
This is a short list of Groovy features I liked, but at the same time, caused me issues. It is key areas to why I believe it is important to learn and understand Groovy as a language before you add in the concepts of Grails, GORM, and other features. Here is a list of a few things that I keep in mind, while writing Groovy code.
Just like you should spend a couple of days learning Groovy w/out Grails, you should spend a couple of days learning Grails w/out developing for your project. The automated scaffolding can be used as part of learning Grails, but I shouldn’t be used for your production code. Also, I would rather have you auto generate the scaffolding and use/tweak it when learning Grails. Once you start building your actual application, start from scratch. Or, better yet, customize the scaffolding generation and then use it to build all of your web pages. In any case, there is a lot of power with the scaffolding (dynamic and generated). Just don’t generate it and then try to tweak it to your desired state. You will end up with a lot of dead code, and code that doesn’t really fit your application — at least that is what happened to me.
I have used Hibernate/JPA for 8+ years. I am a big fan of Hibernate, and appreciate all that I can do with it. I will use various different fetching strategies as needed; one of my favorite is sub-select. However, you need to know your your session life-cycle and use cases to build your application correctly. GORM is great, it does a lot of the stuff for you. The dynamic finders (up to 2 arguments) are fantastic. The amount of boiler plate code using Hibernate with GORM is so much less than writing Hibernate or JPA in Java. That being said, if you are new to Hibernate, GORM will make things easier, but it will also make it harder to understand how and why everything is working.
If you have experience with Hibernate in Java, I would recommend taking a simple object relationship you built in Hibernate/JPA in Java and apply it to GORM/Grails.
This is also where I feel the dynamic scaffolding shines. While I work on a complete technology stack, my expertise is more in the persistence tier. it is also how I think about the application; how am I going to store the data is what I want to work on first. Let Grails help you get that right, before you start working on any of our presentation. Write your GORM entities and relationships, your unit tests, and then use the default scaffolding to visualize use it to see if it “makes sense”. You can work on your transaction boundries, lazy/eager associations, fetching strategies w/out focusing on any of the UI.
This is the one area, I’m very happy with how I developed the initial application. I focused on the persistence tier and tested/used it before building any of the UI. That is because, how I think through a problem domain. Grails/GORM worked perfectly for me. I just wished I threw away the generated scaffolding I played, when I started to work on the actual UI.
GORM’s create/update schema support for Hibernate works very well. While you are getting your initial application working, you should use this functionality. Only after you need to support database migration, would I worry about maintaining your database schema. Letting GORM/Hiberante manage your database for you, forces you to work with a rich object model and letting it create your schema. When I first starting writing Hibernate applications, I was very much of the school of letting your database drive your object model. Over the past 8 years, I have changed to where I prefer the object model to drive the database schema. Grails/GORM encourages that and you will find you enjoy developing more if you can focus on a rich Object Oriented design, instead of forcing in your desired database schema.
Obviously, if you are supporting an existing schema, you cannot do this. For your first Grails application, however, try to create one where you let Grails/GORM handle this for you.
If you are a seasoned Java/JEE Developer, it shouldn’t take you very long to learn Groovy/Grails. Give yourself a couple of weeks of being able to use it, and you will be happy you did. Now convincing your employer to use it; that is a different story.