Home > JavaEE > Hades, your next persistence angel?

Hades, your next persistence angel?

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 to 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:


  

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 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.

To go further:

email
Send to Kindle
Categories: JavaEE Tags: ,
  1. Marcus K.
    January 10th, 2011 at 17:20 | #2

    Hi Nicolas,

    I am using Hades for some time now, currently release 1.6.x because WebLogic (company standard) and JPA 2 do not really work. I like its simplicity while using it. And really complex queries can be implemented via plain old DAO methods: Interface XxxDaoCustom and class XxxDaoImpl are enough to do everything you want. I had some small issues in the beginningof Hades 0.5, but Ollie fixed them very quick. Nothing bad to report from me :-)

    Best wishes
    Marcus

  2. January 10th, 2011 at 20:00 | #3

    Correction done. Thanks for it!

  3. January 10th, 2011 at 20:24 | #4

    Hi all,

    thanks for the nice article. Let me give you a small rational why we introduced transactional CRUD methods in 2.0. To do so, let’s step back to version 1.x without this feature. Most of our users were using Hades in web applications where you typically have some controller in front of a Hades repository. As persisting entities requires a transaction to be running which leads to two possible ways out: making the controllers transactional or introduce a service layer which simply delegates all the methods to the DAO. Especially as with the domain driven approach a dedicated service layer is not unconditionally needed we don’t want to let the user create boilerplate service layer *if not needed* – Hades started because we wanted to get rid of boilerplate code, you remember ;).

    So what are the advantages of the current scenario:

    – no additional transactional layer needed if not necessary for other reason
    – read-only methods run in read-only transactions by default and thus benefit of optimizations Spring applies to those (JDBC driver flag, Hibernate Session not flushed etc.
    – still exact control over how transactions are handled

    So what if you need to come up with your own, more coarse grained business transactions on top of Hades repositories. As Spring’s transaction mechanism uses the first @Transactional annotation found, expanding the scope of an annotation is just a matter of adding a service layer wrapper (which now actually has a purpose) that drives the transaction and delegate to various repository methods. This of course also works if you rather use XML based transaction configuration. Reconfiguring the transaction configuration for the CRUD methods inside GenericDao is just a matter of redeclaring the method inside your repository interface and apply your custom @Transactional configuration there.

    I hope this casts some light on the issue.

    Watch out for the first Spring Data JPA release, it will include major refinements (mostly in naming) and a bunch of new features, including a QueryDsl [1] based alternative to the Specifications, as well as an extension of the method name parser so that you can traverse nested properties. Let’s say you have a Person (entity) with an Address (entity/embeddable) with a ZipCode (field). The you can have:

    public interface PersonRepository implements Repository {
    ListfindByAddressZipCode(String zipCode);
    }

    Feel free to checkout the latest snapshot builds. More information here [2].

    Cheers,
    Ollie

    [1] http://source.mysema.com/display/querydsl/Querydsl
    [2] http://www.springsource.org/spring-data

  4. January 10th, 2011 at 20:30 | #5

    Thanks Ollie for this explanation! Wish you the best for Spring Data.

  1. No trackbacks yet.