Configuring Spring Data JPA

tl;dr Spring Data JPA enables a Repository style of accessing data where the data source is a JPA powered data source. Configuration is simple. Have a working Spring JPA configuration, then add the Spring-Data-JPA as dependency to your project and enable the functionality by wiring the appropriate bean in your Spring Context.

Configuring Spring Data JPA is part of the Configuring Spring Series.

This short post would show how to easily configure Spring Data JPA for use and some related concepts that should help explain the rational behind Spring Data.

Spring Data JPA itself is part of a larger umbrella project: Spring Data. Which seeks to provides an easier, less broiler plate way to accessing data. A lot of the projects under the Spring Data use the Repository pattern, while some don't. Spring Data JPA is one of the projects that implements the Repository Pattern.

Since the Repository Pattern is central to Spring Data JPA, it is recommended to, at least, have an overview of what is going on when it is being used. After this, we go ahead to look at the configuration procedure, which is very succinct.

Repositories can be viewed as abstraction over data. This explanation, although partly correct, does not do justice to the unique identity of the Repository pattern. The question might be, if it is an abstraction over data, how is it then different from DAO's?

There are quite a lot of varied opinion regarding the difference between Repositories and Data Access Objects; but I like this answer to the question on Stackoverflow a lot.

Most specifically the part where it says:

DAO is an abstraction of data persistence. Repository is an abstraction of a collection of objects.

DAO would be considered closer to the database...Repository would be considered closer to the Domain, dealing only in Aggregate Roots. A Repository could be implemented using DAO's, but you wouldn't do the opposite...

This explanation also touches on some key concepts out of Domain Driven Design: Domain and Aggregate Roots. Understanding these also would help groking the essence of Repository pattern itself. Here is a nice blog post that talks about Aggregates and Aggregate Roots in Domain Driven Design. It is a post in a series. The other posts should shed more light on other parts of DDD.

For the more adventurous regarding the subject of DDD; the bible itself is a recommended read. If its 506 pages look intimidating, then maybe a less voluminous guide would be more appropriate: InfoQ Free eBook : Domain Driven Design Quickly. It is just 104 pages.

In short, as can be seen from the explanation of the difference between DAO Pattern and Repository Pattern; the Repository is a collection.

The developer using the Repository is not concerned about the source of the objects. The source could be a Database, a Network, File system, or a Web service. It does not matter. DAO on the other hand, more often than not, deals essentially with the Database.

It is worth nothing here that DAO actually stands for Data Access Object and not Database Access Object. It seems the pattern evolved to mean Database Access Object. :|

So with Spring Data JPA, you work with Repositories which returns to you, objects or collection of objects that are sourced from a JPA based data store.

So with this fact established. The actual configuration is trivial.

Since it is Data JPA, configuring it requires that you have a working JPA configuration in place. You can read Configuring Hibernate JPA in Spring Framework if your JPA provider would be Hibernate. The configuration procedure applies if other JPA provider is being used.

To add Spring Data JPA, you need to do two things. Add it as a dependency in your project (pom.xml in this example as Maven is used) and enable it by wiring the necessary bean in your Spring context.

In pom.xml add:

            org.springframework.data
            spring-data-jpa
            1.4.3.RELEASE

and in your Spring Context add:

jpa:repositories is a Spring xml namespace that serves as a short cut for explicit bean definition needed to get Spring Data JPA running. You can read the section on Hiding Bean Definition via Namespaces for more about this.

The base-package tells Spring JPA Data where to find interfaces it should use in implementing Repository objects for your application. Yes, Spring JPA Data looks for interfaces you specify and provides the actual needed implementation for use at start up. Cool right? This is another way Spring Data JPA makes data access easier with less code. For a more detailed explanation on this, read Working With Spring Data Repositories.

More materials on Spring Data JPA in general can be found on the project page on Spring.io