Hades

= Rationale =
The abstraction of data access layers has established in state of the art Java enterprise applications. The core pattern behind those layers, the [http://de.wikipedia.org/wiki/Data_Access_Object Data Access Object] pattern is also mature and widely accepted. Nevertheless implementing a data access layer is seldom fun but rather boring and results in a lot of boilerplate code.

Technologies === JPA ===
The Java Persistence API was invented in conjunction with EJB3 and serves as standard for persisting objects in JavaSE and JavaEE environments. It abstracts differences of various available OR Mappers like Hibernate and Toplink and guarantees interoperability as far as possible. Although the version 1.0 has its shortcomings, JPA can be considered a future technology.

=== Spring ===
Spring is the defacto standard application framework for Java applications. Its consistent programming model, easy configuration and wide support for all kinds of third party libraries makes it the first class citizen of application frameworks.

=== Spring & JPA ===
Spring offers a lot of support for various technologies in data access area. It's main benefit regarding JPA is the ease and power of configuration along with proper exception translation into Spring's !DataAccessException hierarchy

Problem
80% of data access code is boilerplate. Almost all functionality of DAOs can be implemented with CRUD operations and flexible finders. Thus the aim has to be a generic implementation that serves these 80% well and furthermore allows to implement the other 20% with little extra effort.