Not using Spring Data yet? Well, you should, and here's why.

In pretty much every single project you will ever work in there will be a need to persist data. Typically you will use things like JPA, Hibernate, and similar APIs. Using these APIs is a huge step forward compared to the good ol' days when we didn't have things like O/R mappings and nice transactional APIs but had to fiddle around with JDBC connections, rolling back transactions, reading from result sets and whatnot.¹ But still, pretty much all of the work you do every time you create a repository class for your entities is plumbing. You are creating nothing but boiler plate code. And time spent on boilerplate code is time wasted, because you are writing code that adds no real value but still needs to be tested and maintained.

If you recognize any of what I was just talking about i highly recommend you take a look at the Spring Data open source project if you are not already familiar with it. The reason being that it can significantly reduce the amount of time you need to spend on creating persistence for your entities so you can focus on whats important; your business logic.
The Spring Data project contains several sub-projects that provides support for various storage solutions like JPA, Hadoop, Neo4J, Redis, MongoDB etc. so it has potential to suit the needs of a wide variety of projects.

A quick example

Let me show you a couple of examples on how a JPA repository would look like using Spring Data JPA.

Let say we need to store users. We would then create a User entity. This would look just as it usually does as per standard:

@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;
    @Column(nullable = false)
    private String firstName;
    @Column(nullable = false)
    private String lastName;

Then all we need to do in order to create a repository that will provide us with CRUD- and some additional retrieval operations is to create a single interface. Like this:

public interface UserRepository extends JpaRepository<User , Long> {}

The interesting part here is that we extend the interface JpaRepository. This interface will give us methods like findAll(), delete(user), save(user) and so on.

To create custom queries you simply create methods in your UserRepository interface. The name of the methods will determine what the query will be. For example we could modify our repository to look like this:

public interface UserRepository extends JpaRepository<User, Long> {

    public List<User> findByFirstNameOrderByLastNameAsc(String firstName);

    // You can use getBy as well as findBy
    public List<User> getByFirstNameLike(String firstName);
}

There are several keywords that are available for use in method names and if that is not enough you can also create custom queries in several different ways. You can read more about the possibilities in the reference documentation.

What really appeals to me is the how clean a solution this will give you. It allows me to spend a minimal time on getting persistence and then let me go on and focus on whats important. A single interface is about as clean as it gets. And clean is good.

I have just scratched the surface here on how Spring Data works and there are a lot more features in Spring Data JPA and if you have the need you can get some pretty advanced usage out of it.

The example code for the UserRepository shown here is on GitHub so you can see how it works and play around with it a bit.

Have fun!

----------------------
1) I actually know some that still wrestle at the JDBC level and I feel sorry for them. There are very, very few times when that can be justified in my opinion. Very few.