Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Sizing Up Open Source Java Persistence : Page 3

Confused and puzzled by the plethora of persistence options in Java? You are not alone. Examine how some popular open source persistence frameworks stack up against one another and JDBC.


advertisement
Learning Curve and Support
Discerning which of the frameworks provides better support and a gentler learning curve is a bit subjective. However, there are a couple of factors to explore that might help quantify the time to spin up and obtain help when needed.

Documentation and Support Sites
The good news is that all of the frameworks explored in this article provide a Web site with examples, tutorials, and online documentation. The detail and organization of these Web sites does differ a bit. In my opinion, Hibernate and JPOX JDO offer more documentation than Castor or iBatis. JPOX JDO provides extensive documentation, but without a search capability and because of its size, it can be a bit unwieldy to find the appropriate example. Hibernate offers documentation in a single page HTML file or PDF to make searching easy.

Hibernate and JPOX JDO also offer design tips beyond the simple how-to documentation. JDO frameworks like JPOX also benefit from being an implementation of a specification. The Sun site helps provide more general information and explanations of JDO technology that can assist with any implementation.



All of the frameworks have official and unofficial forums or mailing lists for getting questions answered and for seeking help. The table below is not a complete list, but will give you some places to go for more assistance. This list does not include the framework's project development forums and mailing lists. Developers working on the framework typically frown on posting end user questions to the development forums for obvious reasons.

Framework

End-user Forum/Mailing list(s)

Hibernate

http://forum.hibernate.org

Castor

Subscribe to the mail list through user-subscribe@castor.codehaus.org

JPOX JDO

http://www.jpox.org/servlet/forum/index

JDOCentral JDO 2.0 forum http://www.jdocentral.com/forums/index.php?showforum=10

iBatis

Subscribe to the mail list through user-java-subscribe@ibatis.apache.org

http://www.nabble.com/iBATIS-f360.html

JDBC API

http://forum.java.sun.com/forum.jspa?forumID=48

http://www.jguru.com/forums/JDBC

http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=forum&f=3

Subscribe to the mail list through http://archives.java.sun.com/jdbc-interest.html


Table 2. Persistence Framework Forum/Mailing Lists: This table lists the more popular forum and mailing lists for each.

During the research and work for this article, I posed several questions and issues to many of these sites. I found that helpful responses usually came within one week or less. Only in one case, using the Castor mailing list, did I not get back an answer before this article was published. However, even in this case, I did get a request for more code to be sent to their JIRA developer mailing list for examination and future response.

Help in Books and on the Web
Based on a quick, unscientific appraisal of available resources on the Web and in bookstores, JDBC comes out way ahead of the others in terms of helpful resources; Hibernate is a distant second.

Figure 1. Professional Help: This chart depicts framework skills listed on resumes posted to Monster.com.

If you are a manager, architect, or team lead on a project considering using one of these persistence frameworks, finding developer help with prior experience in a technology is a valid part of your evaluation criteria. Certainly finding someone with JDBC or even Hibernate experience is easier. Finding people with the other framework skills will be a little harder to find as represented by a recent search of resumes on Monster.com. While the number of people with appropriate persistence framework skills is not known, the chart in Figure 1 depicts framework skills listed on resumes posted to Monster.com. The number of results returned is capped at 1000 so the JDBC results are not reflective of the actual numbers of available resources.

Flexibility: How Well Do They Lie on Top of the Existing Models)
Persistence frameworks should be flexible. A key premise of this examination of Java persistence frameworks is that the database and Java objects should not have to change in order for the framework to do its job. On many software projects, the database or even some of the application business object code may already exist. Even where these have not been created, should the data or object model be formed around what the persistence framework supports? I contend that the answer is a definitive NO! So, the first big caveat regarding this comparison is that if your application or database design can be fashioned around the other and/or the framework that maps one to the other, then the results of this comparison might not align with your needs. Most developers do not have that luxury of a green field in data or object model design.

Happily, one of the biggest surprises of this examination is that, in general, these frameworks do adapt well to existing object and data structures.

The Test Model
In this comparison, I devised two models through which to examine each framework. The two models and their code are attached in this zip file. The first model is really just a simple model to make sure the framework, code, and database are working properly. The single Java class and its accompanying database table are shown in Figure 2.


Figure 2. Simple Java Object/Database Table: This simple Java is mapped to a single simple database table.
 
Figure 3. Java Object/Database Table Person Model: Both customers and employees associated to an organization are represented in Java objects and database tables.

The second model is more extensive and meant to test a wider range of framework properties and features (see Figure 3). This model shows inheritance, many-to-many, many-to-one, and one-to-one associations. You can also see that there is a diversity of property types in the classes/tables. People may be associated to a set of addresses. Employees may be associated to organizations and a "user" which represents the person in information systems.

Could the second model be even more complex? Certainly, and your classes and database schemas will likely make this simple model seem trivial. It is, however, enough to get an understanding of some of the basic differences between the frameworks.

The Test DAO Interface
Most experienced developers try to isolate the various tiers of their application. The business objects, like those designed above, do not change, or change rarely, whereas the persistence framework, user interface, etc. might change frequently. In fact, this examination is a case in point where the persistence framework changes frequently from Hibernate, to JDO, etc.

A data access layer (see Figure 4), defined by the interface shown in the code below, was implemented for each persistence framework, regardless of how it is implemented under the covers. In general, the frameworks were all able to lie on top of the existing models and satisfy the needs of this interface with little difficulty:

public interface PersonDAO { public static final boolean debug = true; public void saveEmployee(Employee employee) throws Exception; public void deleteEmployee(Employee employee) throws Exception; public List findAllEmployees(); public Employee findOneEmployee(long id); public void saveCustomer(Customer customer) throws Exception; public void deleteCustomer(Customer customer) throws Exception; public List findAllCustomers(); public Customer findOneCustomer(long id); public void saveSimple(Simple s) throws Exception; public void deleteSimple(Simple s) throws Exception; public List findAllSimples(); public Simple findOneSimple(int id); }

Figure 4. Data Access Layer: This was implemented for each persistence framework.

Figure 4 shows that the tests performed against each of the persistence frameworks required general data access to find, create/save, update, and delete instances of the models in Figure 2 and Figure 3. The data access layer, as defined by the PersonDAO interface, facilitated these common operations in each framework

Flexibility Results
So how well did each persistence framework lie on top of the existing data/object models and implement the access layer? Quite well! In fact, none of the business classes or the database tables had to be modified for these tests.

While the models did not have to change, a couple of small issues and considerations involving the mapping between objects and data tables were discovered:

  • Some of the frameworks rely on and take advantage of table foreign key definitions. Other frameworks have difficulties with some of these definitions. As an example, JDO used a foreign key relationship to help record ids in the related objects when they are created. Those same foreign key definitions created dependency issues (especially when deleting objects) in other frameworks. Although not obvious through the documentation, I believe many of the foreign key issues could eventually be solved by configuration.
  • iBatis does not innately handle a character primitive property/column mapping. So, the gender property on the Person class/table presents some unique challenges for negotiating in or out of Strings as part of the mapping activities. This is because iBatis is based heavily on the capabilities of JDBC PreparedStatements, which do not provide a means to set a character parameter.
  • The intertech_users table has an employee_id column which, as it turns out, is a redundant column. In the database, employees can be related to users through the user_id column on the employees table. When saving an employee object related to a user object some of the frameworks handled populating this redundant column in the database. Others, like Hibernate, saw no need to populate the redundant column.
As you map your objects to database tables, you will undoubtedly come into contact with little issues like this. Give yourself time to deal with issues like these. Depending on the size and complexity of your model, they can be quite common.

Bottom line: the complexity of the code to implement the simple CRUD activities differed substantially (covered later is this article), but the ability to implement this base functionality without the need to change the models (object or database) is met by each framework.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap