Java Notes From My Desktop

Tags - Categories : All | Articles | Book Reviews | CSS | Java | Javaranch | Javascript | News | Opengl | Opinions | Personal | php
ORM Tools are good but are they the end all solution when it comes to persisting data in your application and the data access layer? This is a question that has been waying on my mind a bit while working on a current project. I have been playing around with Hibernate to see if it would suit my needs. In terms of other ORM API's, I think Hibernate is probably one of, if not, the best. But do I need to use it? It's got a bit of a learning curve and, in my opinion, it adds a level of complexity to my application that I wonder if needs be there.

As an alternative I have been testing different ideas of my own. One being to create a JavaBean for each table with methods like insert(), remove(), update(), etc. After creating a couple of these JavaBeans I remembered a project created by Paul Wheaton (Javaranch Owner) and Marilyn de Queiroz (Javaranch Sheriff) that is part of the Javaranch Commons package called Jenny.

To put it simply, and from the Jenny home page, Jenny "...reads a database and generates java source which provides strongly typed access to the database." Basically Jenny creates a JavaBean with the appropriate getter and setter methods for a table and provides those common methods that I mentioned before as well as some others.

You provide Jenny a properties file with information about the database, what JDBC Driver to use, and what package the source code should be placed in. Jenny will also create mocks for all of her generated classes to help with your unit testing. Then it's just a matter of executing Jenny from the command line feeding it the properties file to use and Jenny spits out the source code for you.

It's really quite simple and provides a pretty good data access layer for any application.

There is a good tutorial on using Jenny that you can use to get started. Interestingly, that 1 page tutorial is all you need. Compare that to a 150 page Hibernate manual!

Jenny's main shortcoming is that there is no built in caching. If you need that then you would have to build that layer yourself. And that might be a bit tricky with Jenny because the classes are directly linked to the database.
I agree. And I thought about mentioning that in my blog entry. But decided to ignor that fact for now. But you are correct. ORM Tools like Hibernate do have some super nice caching facilities. However, the added complexity for a simple web app is still the major concern for me.
IMO caching of single records should be performed whereever possible at the database and not in the persistence framework anyway. Let the database worry about query performance (within reason) by returning cached results and keeping track of changes, it's what it's there for!

From a brief look at the FAQ, it seems the names of the beans and their getters/setters are taken directly from the database rows. It therefore follows that if you want to use the camel notation (e.g. thisIsAnotherNotation) your db has to support this naming scheme. I assume that whilst you could provide a name mapping you don't want to in order to keep jenny as simple as possible?

Also, does Jenny have any support for generating relationships automatically from foreign key mappings?



Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 7 + 1 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/gthought/addTrackBack.action?entry=1081191916000