A brief comparision between development with Hibernate and Entity beans

I hope to get a rough performance comparison of an enterprise application using entity beans for persistance compared to using Hibernate soon, in the meantime I thought that a brief comparison of the development effort involved in using the two approaches might be in order. Comparisons are based on JBoss 3.2.2 running MySQL.

Installation

JBoss comes as a working EJB environment, therefore no extra installan over and above getting JBoss itself installed is required. For Hibernate, due to a JBoss-related classloader issue you have to deploy the Hibernate jar and related dependencies to the server’s lib directory.
Application development

JBoss requires an application.xml file, and ejb-jar.xml XML file containing the entity and session mean mappings, and a jboss.xml file containing the JNDI mappings. Hibernate requires a single Hibernate config file, and a single XML mapping file per bean – this defines the mapping between JavaBean property and database fields, as well as inter-bean relationships. If you were using Hibernate in a webapp, you would of course require a web.xml, and if you were using it in an normal Enterprise application (for example you we using Session beans to manipulate Hibernate objects) you would need the aforementioned application.xml, ejb-jar.xml and jboss.xml files. For JBoss when adding new entity beans, mappings need to be changed in the ejb-jar.xml and jboss.xml files – Hibernate requires a new bean mapping file and a related entry in the Hibernate config file.
Development

Creating a standard entity bean requires a new Java class to be created, a stub interface that will be used by clients, and a home interface which will be used to access finder methods and creation methods, and optionally 2 more interfaces (if you want both local and remote interfaces) in addition to having to add a JNDI entry and a mapping in the JBoss config files. There are a mass of consistency checks that have to be carried out (often by the developer due to the poor validation provided by many EJB containers) – for example the parameters in your Home interfaces create method must match perfectly with the parameters in your bean implementation’s ejbCreate method, which in turn must match the ejbPostCreate method. Few of these consistency checks can be carried out at compile-time – they have to be confirmed by the container itself. Once created, you’ll have to create the database structure for your new bean.

With Hibernate, you create a single Java class which is a standard JavaBean. You then create a mapping file which maps the JavaBean’s properties to database columns. Hibernate in fact includes tools to either create the JavaBean file from a mapping file, or a mapping file from a JavaBean class. In addition it ships with the SchemaExport program which can read your database mapping and automatically create the database structure (including columns required for mapping relationships).

When it comes to actually persisting data, Entity beans perform this completely transparently. You just have to call the relevant setter method on the bean, and it gets written to the database (depending on your transaction management). With Hibernate a specific call to the session is required.

Defining relationships between objects in both JBoss and Hibernate is done via configuration files, however Hibernate’s method seems much simpler despite being at least as powerfull.
Conclusion

Whilst is probably too soon to say (I’ve been using EJBs for three years now and Hibernate only in my spare time for about a week) I am really warming to Hibernate. I suspect that baring any real problems with its performance or more advanced capabilities my next Enterprise application will use Hibernate for persistence.