A year ago, a colleague of mine showed me a very interesting framework named Krank (latter renamed to Crank because the previous name means "sick" in German, which does not bode well for any framework). Crank’s goal was to ease development on top of Java Persistence API 1.0. Two interesting features caught my attention at the time:
- a generic DAO which implements CRUD operations out-of-the-box. This is a Grail of sort, just try to Google for "Generic DAO" and watch the results: everyone seems to provide such a class. Whether each one is a success, I leave to the reader.
- a binding mechanism between this generic DAO and named queries, releasing you from the burden of having to create the query object yourself
Unfortunately, there’s no activity for Crank since 2008 and I think it can be categorized as definitely dead. However, and I don’t know if there’s a link, a new project has emerged and not only does it implement the same features but it also adds even more innovative ones. This project I’ve only recently discovered is project Hades, which goal is to improve productivity on the persistence layer in general and for JPA v2 in particular. It now definitely stands on top of my "Hot topic" list.
In order to evaluate Hades, I’ve implemented some very simple unit tests: it just works, as is! Let’s have an overview of Hades features.
Configuring Hades
Hades configuration is based on Spring, whether you like it or not. Personally, I do since it makes configuring Hades a breeze. Hades uses a little known feature of Spring, namely authoring, in order to do that (for more info on the subject, see my previous Spring authoring article). Consider we already have a Spring beans configuration file and that the entity manager factory is already defined. Just add Hades namespace to the header and reference the base package of your DAO classes:
<beans...
xmlns:hades="http://schemas.synyx.org/hades"
xsi:schemaLocation="...
http://schemas.synix.org/hades http://schemas.synyx.org/hades/hades.xsd ...">
<hades:dao-config base-package="ch.frankel.blog.hades.dao" />
</beans>Since Hades uses convention over configuration, it will:
- transparently create a Spring bean for each of your DAO interface (which must inherit from
GenericDAO) in your configured package - reference it under the unqualified class name where the first letter is set to lower-case
- inject it with the default entity manager factory and transaction manager provided they are respectively declared as "entityManagerFactory" and "transactionManager"
Generic DAO
Hades generic DAO has support for standard CRUD operations on single entities and whole tables, plus COUNT. Under the cover, it will use the injected entity manager factory to get a reference to an entity manager and use the latter for these operations.
Named query
Using a JPA’s named query needs minimal boilerplate code (but still) and do not provide a generics signature (which will need to be cast afterwards):
Query query = em.createNamedQuery("findUsersByName").setParameter(name);
List result = query.getResultList();Hades, on the other hand, provides a binding mechanism between a named query and an interface’s methode name:
public interface UserDao extends GenericDao {
List<User> findUsersByName(String name);
}Now, you just have to inject the DAO into your service and use it as is.
Simple criteria query from method name
Most of named queries you write manually are of the form SELECT * FROM MYTABLE WHERE A = 'a' and B = 'b' or other simple criteria.
Hades can automatically generate and execute queries that are relevant to your method name.
For example, if your DAO’s method signature is List findByLastNameOrAgeLessThan(String name, Date age), Hades will create the associated query SELECT * FROM User u where u.lastName = ?1 and u.age < ?2 and bind the passed parameters.
Although I was a bit wary of such feature based on method’s name, I came to realized it ensures the semantics of the method is aligned with what it does. Moreover, there’s no code to write! Truly, I could easily fall in love with this feature…
Enhancing your DAOs
Crank’s generic DAO had a major drawback. If you wanted to add methods, you had to create a concrete DAO class, compose the DAO with the generic one, then delegate all the standard CRUD operations to the generic. You could then code the extra methods on your concrete DAO. At least, it is the design I came up with when I had to do it.This was not very complex since delegation could be coded with your favorite IDE, but it was a bore and you ended up with a very very long class full of delegating calls. Not what I call simple code.
Hades designed this behaviour from the start. When you need to add methods to a specific DAO, all you have to do is:
- create an interface with the extra methods
- create a concrete class that implements this interface and code these methods. Since you use Spring, just reference it as a Spring bean to inject the entity manager factory
- reuse the simple DAO interface and make it extend your specific interface as well as
GenericDao(like before)
Done: easy as pie and beautifully designed. What more could you ask for?
Conclusion
Hades seems relatively new (the first ticket dating back from April 2009) yet it looks very promising. Until then, the only "flaw" I may have see is transaction management: CRUD operations are transactional by default although, IMHO, transactionality should be handled in the service layer. However, it is relatively minor in regard to all the benefits it brings. Moreover, reluctance to use such a new project can be alleviated since it will join the Spring Data in the near future, which I take as a very good sign of Hades simplicity and capabilities.
As for me, I haven’t use but taken a casual glance at Hades. Does anyone has used it in "real" projects yet? In which context? With which results? I would really be interested in your feedbacks if you have any.
As usual, you can found sources for this article here.