Difference Between Spring DAO vs Spring ORM vs Spring JDBC

The Spring Framework is an application framework and inversion of control container for the Java platform. The framework’s core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform.

Spring-DAO 

Spring-DAO is not a spring module. It does not provide interfaces or templates to access the data. One important change that needs to be written while using Spring DAO is, that it has to be annotated with @Repository. The reason for doing this is the exceptions that may arise in the underlying technology like JDBC, Hibernate, JPA, etc. are consistently translated into their respective DataAccessException subclass. Let us see this with one example of a Student service scenario.

Initially, Hibernate is the persistence mechanism that got used.  Suppose let us assume that HibernateException is caught at the service layer. There should be steps available to catch it. But at some point in time, instead of Hibernate, it has been changed to JPA, then no need to change the DAO interfaces. 

Instead, if it is annotated with @Repository, then the exceptions related to the current underlying technologies will be directly translated to the spring DataAccessException. Because of this feature, though the underlying technologies are changed from hibernate to JPA or from JPA to hibernate, then the same Spring DataAccessExceptions will still be thrown. According to the underlying technologies, the spring will translate according to their native exceptions.

Limitations in using Spring DAO related to the exceptions

• Should not catch persistence exceptions
• The hierarchy of exceptions is usually richer and more meaningful than the one provided by spring. But there is no mapping from one provider to the other. The reason for adding @Repository in the DAO is the beans are automatically added by the scan procedure. Spring has the tendency to add other useful features to the annotation.

Sample code snippet related to Spring DAO. Service implementation layer has to get annotated with @Repository followed by its corresponding service layer.

Java

// Necessary imports
@Repository('<Specify the DAO that is getting accessed')
// Eg : StudentDAO
public class StudentDAOImplementsation
    extends HibernateDao<Student, Long>
    implements StudentDAO {

    @Override public boolean remove(Student studentObject)
    {
        // Write necessary steps
        return true;
    }
}

Spring ORM

Spring-ORM is a very efficient module that plays as an umbrella pattern. The reason for calling this an umbrella is it covers many persistence technologies, namely JPA, JDO, Hibernate, and iBatis. For every individual technology, integration classes are provided by Spring. With that integration classes, each technology integrates easily with Spring transaction management. Mainly injection of DataSource is done via SessionFactory or EntityManagerFactory etc. bean. In the case of pure JDBC, apart from JdbcTemplate, there is no need for any integration class as JDBC(Java database connectivity) directly relies on data sources. For each technology, the configuration basically consists in injecting a DataSource bean into some kind. For pure JDBC, there’s no need for such integration classes (apart from JdbcTemplate), as JDBC only relies on a DataSource. Spring-JDBC is not required in the case of ORM like JPA or Hibernate but Spring-Data is required. Spring-Data is nothing but an umbrella project and it can provide a common API that defines accessing the DAO and annotations and it covers both SQL and NoSQL data sources. Model classes have to get annotated with @Entity and in that primary key has to get annotated with @Id. The sample code for Student Model Class is given below.

Java

// Necessary import statements

// This is much required and here model class
// should match with database table name
@Entity
public class Student {
  @Id
  private int studentId;
  // other necessary attributes like name, address etc.,
  // Corresponding getter and setter methods
}

Spring ORM DAO and service class has to get annotated with @Component

Java

// Necessary import statements
@Component
public class StudentDAO {
  @PersistenceContext
  private EntityManager em;
  // Rest set of code
}

Spring JDBC

JdbcTemplate class is provided by Spring-JDBC.  It directly helps to check out SQL queries and parameters. No need to worry about the plumbing code as it does not require that. Configuration with a DataSource is mandatory. The sample code is given below.

Java

// necessary import statements
int totalStudents = jdbcTemplate.queryForObject("select count(1) from Student", Integer.class);
Student student = jdbcTemplate.queryForObject("select name, address from Student where id=?",
            rs -> new Student(rs.getString(1), rs.getString(2)),
            12345);

The advantage of using Spring-JDBC is it provides a JdbcDaoSupport, It is useful for extending DAO. It has 2 properties namely a DataSource and a JdbcTemplate. They are helpful for implementing DAO methods. Additionally, there is an exceptions translator available which translates from SQL exceptions to spring DataAccessExceptions.

Difference Table

Spring DAO	Spring ORM	Spring JDBC
Generalized concept and @Repository annotation are mandatory.	Easy integration with Spring with the following SessionFactory for Hibernate EntityManagerFactory for JPA SqlSessionFactory for MyBatis	For plain JDBC calls.
Data access implementation is totally separated and hence it is independent of the database.	Multi-technology implementation is possible by integrating with the required tools.	If the application is not complex and diversified and lies on a single database, we can use this and it is efficient.
An additional layer and its dependencies need to be specified. Hence it may take some time to start if the application is complex.	An additional layer and its dependencies need to be specified. Hence it may take some time to start if the application is complex.	As this is straightforward, no complex dependencies are required but portability will become less if we use this.
Maintenance issues will be there because of the complexity of the additional layer.	Maintenance issues will be there because of the complexity of the additional layer.	Here less maintenance only.
Design patterns like Factory classes, and Data Transfer Object(DTO) are needed to get implemented along with DAO.	Got the support for multiple technologies like Hibernate, JPA, and iBatis.	Implementation is simple. If relying on a single database and direct query purpose means can depend on this.