I followed the path set by Mikael, and tested some components that I hadn’t really tested before on my own properly. I was honestly surprised how these bits and pieces had improved – and how Spring Framework-integrations make life so much easier.
The first new component or program I tested was DbSchema, which is a simple database design tool. Normally I wouldn’t like to play with a tool like this, but as part of this testing I wanted to see it. And to be honest it was actually fun to see and model the table structures visually, and finally export the sql into the project. Thought the created sql is not of the type I would manually write, it seems to work properly in different databases – so there is some use to the product to be used in projects, where you need to often refactor the database structure and use multiple database engines.
Related to this I wanted to finally properly see what is it like to use embedded databases in your own projects – either to test the persistence layer without a proper database instance in unit tests or just for the fun of it. I asked opinion from Mikael and settled to use H2 instead of Derby or HSQL. Spring’s support for embedded databases was surprisingly easy to take into use. Just few configuration lines and two files of sql – and I had an initialized database in my application at my disposal, when needed. How much better can it get?
Interesting bits and pieces don’t come in the setting up the datasource, but from different methods of using it. Spring JDBC and especially NamedJdbcTemplate has been a powerful tool in many occasions, but as we all have learned to know – writing low level crud-code is tiresome. Spring ORM support – and especially the JPA support improves things a lot, but still leaves you to write boilerplate data access layer for basic operations. Spring Data JPA changes this.
I was a little vary first, but became a sort of convert after reading through Mikael’s posting, reading through the documentation a bit – and then finally testing it in my own application. I am usually quite skeptical on frameworks that promise to much and are filled with magic, but eventually do not deliver – but do not reveal that until you have already painted yourself into the corner.
Spring Data’s JPA support was impressive – as it allows you to leave out writing boilerplate code, extend the automaticly created repository bean with your own code and eventually of course replace this proxyed code with manually written dao — if you choose to do so. As the usage model and api does not include anything extraordinary, you don’t create a forced lockin with the implementation – but rather can choose whether you write something or trust the proxy bean Spring gives. See more about that in the documentation section ”1.4. Custom implementations”.
The one thing that bores me, is the fact that setting everything up and configuring all the dependencies ready for a project usually takes a lot of time, but then again after you lay down the foundation once — you can use and reuse that numerous times. I’ll take that over frameworks where all the options have decided for you and are dead bolted so that nothing can be changed easily.
Do the setup work once, enjoyment for life.