Archive

Posts Tagged ‘persistence’

Hades, your next persistence angel?

January 10th, 2011 5 comments

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:

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

To go further:

Categories: JEE Tags: ,

Spring Persistence with Hibernate

March 1st, 2010 No comments

This review is about Spring Persistence with Hibernate by Ahmad Reza Seddighi from Packt Publishing.

Facts

  1. 15 chapters, 441 pages, 38€99
  2. This book is intended for beginners but more experienced developers can learn a thing or two
  3. This book covers Hibernate and Spring in relation to persistence

Pros

  1. The scope of this book is what makes it very interesting. Many books talk about Hibernate and many talk about Spring. Yet, I do not know of many which talk about the use of both in relation to persistence. Explaining Hibernate without describing the transactional side is pointless
  2. The book is well detailed, taking you by the hand from the bottom to reach a good level of knowledge on the subject
  3. It explains plain AOP, then Spring proxies before heading to the transactional stuff

Cons

  1. The book is about Hibernate but I would have liked to see a more tight integration with JPA. It is only described as an another way to configure the mappings
  2. Nowadays, I think Hibernate XML configuration is becoming obsolete. The book views XML as the main way of configuration, annotations being secondary
  3. Some subjects are not documented: for some, that’s not too important (like Hibernate custom SQL operations), for others, that’s a real loss (like the @Transactional Spring annotation)

Conclusion

Despite some minor flaws, Spring Persistence with Hibernate let you go head first into the very complex sujbect of Hibernate. I think that Hibernate has a very low entry ticket, and you can be more productive with it very quickly. On the downside, mistakes will cost you much more than with old plain JDBC. This book serves you Hibernate and Spring concepts on a platter, so you will make less mistakes.

Categories: Book review Tags: , ,

Framework agnostic JPA

March 10th, 2009 No comments

With new JEE 5 standard has come the EJB3 specifications. From an historical point of view, EJBs come into 3 different flavors: (i) Entity for persistence, (ii) Session for business logic and (iii) Message-Driven for listeners. Entity EJB are the most time-consuming to develop in their 2.1 version. Apart from the inherent complexity of EJB (local and remote interfaces, homes), developing an EJB 2 is error-prone because of the mapping mechanism. All in all, EJB 2 development really needs a very specialized IDE and expert developers. That’s the main reason why EJB 2 didn’t achieve a significant market share, and had to compete with JDO, Hibernate and other third-party frameworks.

Sun eventually realized this and did come with a much simpler solution with EJB 3. Using Java 5 annotations, developing Entity EJB 3 is a breeze. The part of EJB 3 specifications that deal with Entity is called Java Persistence API (JPA). It is a specification in its own right, and in the next specifications, it will have its own. Developing JPA applications is a two-step process. First, you have to create you model classes. Such classes will be the foundation of your persistence layer: it would be a good idea to use this layer throughout your entire organization, since these classes should closely map your database model. A simple JPA enhanced class would look like this: Read more…

Categories: Java Tags: , ,