Last night I downloaded and got my first sample program running on grails.

I had been reading about grails for a while- so decided to check on the hype myself

And I was…fairly surprised- pleasantly to see what it had to offer

The time between downloading grails and having it up and running with a small program, not a hello word program – but an actual program which would list and add objects,  was somewhere between 10-15 minutes.

Doing the same thing in Java from scratch would have taken me- well ages.

I know Grails has a strong integration with Spring- so I guess it should be able to deliver lots if not all the advantages that Spring has to offer.

Grails is built on top of Groovy- which is in turn built on top of Java.

I for one do not want to retire Java – just because it has outlived its life and its time for more snappy languages to move in. The romance of somewhat new syntax while still have the familiarity of Java  doesn’t excite me too much

The luxury of not adding semi-colons at the end of line-may excite some people- but it doesn’t tickle me to death that I wont have to worry about any more. Years ago when i would struggled with compilation errors- yes at that time- it would have been a help- but personally its too late for me to benefit from this

The one thing that bothers me is the speed- since Groovy is  built on top of Java- it will be  factor slower than Java. That factor can be reduced but not eliminated.

What remains to see if does the advantages of Groovy outweigh this factor?

 

About the author

I came across this book by Mark Richards- Java Transaction Design Strategies. For those who are not from Boston area- mark is a much familiar face in the NEJUG meetings- ever second Thursday. He served as the President for quite some time.

The book:

The book is about Transactions- in java applications- using EJB or Spring

Mark has done a good job of drawing a distinction between Transaction Models vs Transaction Strategies. Transaction Model is how you declare your transactions. Transaction strategy on the other hand is putting together a strategy on where to put transactions and who is responsible for what.

Throughout the book- he draw examples and contrasts Spring and EJB.

Code examples are minimal- its more of easy to read and grasp language. I personally do not like books with lots of code- so this went well with me. This book has been deliberately written in a concise manner – which it makes it easy to read and finish

The book is divided in two parts. The first part introduces the three Transaction Models- Local Transaction Model, Programmatic Model, Declarative Model. It also provides a recap of common transaction related terms- JTA ,JTS, ACID, Isolation levels,XA transactions, Two phase commit,Heuristic Transactions, LPS

Second Part discusses three design patterns- Client Owner Transaction Design pattern, Domain Service Owner Transaction Design Pattern,Server Delegate Owner Transaction Design Pattern.

Best Practices suggested in this book:

In declarative transactions: Make the class level transaction- most restrictive , and then fine tune for individual methods as needed

The method that starts the transaction- should be the one to commit or rollback

If a method requires a transaction context – but is not responsible for  marking it as rollback- then it should have an attribute of  Mandatory

Use XA only of you have multiple resources participating – in tech same transaction context

I enjoyed reading the book and would recommend to anyone- seeking a quick and clean introduction to Transactions with a touch of Java and Spring

You can get the book from here
.

 

Visit to the bank

You walk in to the bank- to deposit cash.

You stand in the line- meet the Teller who does the transaction with you.

Do you really  care whether its Joe or Mary behind the counter?

No. You do not.

Because your contract with the Bank is via the teller (:read interface) not Joe who happens to be there – that day or maybe everyday (:read implementation)

It’s all about the contract

Interface is nothing but a formal contract . All classes which implement that interface- are basically declaring that we will honor this contract and will provide you the service as said by this interface.

The beauty of this paradigm is that – this keeps your two classes blissfully unaware of each other – allowing you to change one without drastically affecting another or at least controlling the affect on another.

Examples

Java API is actually full of very good examples of this.

e.g. JDBC Driver . All JDBC applications use the Driver interface – to get a connection etc.

Because we program against this Driver- we do not care what that implementation is.

The implementation could be an Oracle Driver or a MySQL Driver.

Your application would work the same- for both the databases- as long as you have programmed to the interface- without depending upon the actual implementation.

Another example: Java Collection API List,Set,Map Interfaces.

If your classes take as input one of these interfaces- the caller may send you a different class- ArrayList or LinkedList- and you wont notice a thing. That’s why its strongly encouraged that your input parameters or return types should be an interface rather than a class.

And Spring

The best thing I like about Spring is- it strongly encourages you to program to interfaces by using Config files- which bind implementing classes to each other using interfaces

You code uses only interfaces you refer to implementation only in the config file

How do I know if I did program to interfaces or not ?

Look at the input parameters and return type of your public API.

If you return a class rather than an interface- you are exposing your implementation detail.The caller is not programing to your interface -but to your classes.

If the input parameters of your public API is a class- you are dependent upon the internal implementation of the caller- and not on it’s interfaces.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha