Spring DAO

Spring DAO

In this tutorial, we are going to discuss spring DAO. DAO stands for Data Access Object. It is a design pattern. It can provide an excellent environment to separate Data Access logic from Business Processing logic. In enterprise Applications, to prepare a Data Access Layer, we will use the DAO Design pattern.

Spring DAO
Advantages of DAOs in Enterprise Applications
  • We can hide all data access implementation from the Business/ Service Layer.
  • It is very simple to switch the data access layer from one data access technology to another without giving any effect to Service/Business Layer, that is, from JDBC to Hibernate, etc.
  • DAOs can provide centralized Data Access in enterprise Applications, and it simplifies the maintenance of Enterprise Applications.
  • While preparing Service/Business layer Code Simplification is possible, it is very simple to prepare Service/Business layer.
  • We can get Standardization to prepare the Data Access layer with DAOs.
Drawbacks with DAOs
  • It adds one more layer to the enterprise Application, which may cause maintenance problems.
  • Along with DAOs, we have to implement other Design patterns like Factory Classes, DTO [Data Transfer Objects], etc., in enterprise applications.
Guidelines to prepare DAOs in Enterprise Applications
  1. Prepare a separate DAO interface with the required DAO methods, which must represent CRUD operations.
  2. Provide an implementation to DAO interface
  3. Prepare DTOs as per the requirement
  4. Create Factory Methods/ Factory Classes to generate DAOs
  5. We must not cache DAO references because Factory classes/ Factory methods provide single instances of DAO to the service layer. If DAO is required in multiple modules, it must create more than one DAO reference.
  6. In the case of DAOs, it is suggestible to interact with Databases by using Connection Pooling mechanisms, not by using the DriverManager approach.
  7. DAO is not thread-safe; we must not use DAOs in a multi-threaded environment.
  8. In DAOs, we can access the close() method to close the resources like connections, so here, before calling the close() method, we must ensure that whether the resources are going to be released or not with our close() method call.
  9. We have to make sure that all the objects which are used by DAOs follow Java bean conventions or not.

To support DAOs kind of implementations in Spring Applications, Spring has provided a separate module called “Spring DAO.” Spring DAO modules have provided a set of predefined classes and interfaces to provide DAO support in the form of “org.springframework.dao” package.

In Enterprise Applications, to prepare Data Access Layer or DAO layer Spring has provided Modules in the form of JDBC and ORM. In ORM, we may use the number of ORM implementation tools like Hibernate, JPA, etc.

In Enterprise Applications, to prepare Data Access Layer, we have already Plain JDBC tech. Then what is the requirement to go for Spring JDBC Module?

  1. To prepare Data Access Layer in enterprise applications, if we use JDBC, we must take explicit responsibility to prepare the steps load and register the driver, Establish Connection, create a Statement, execute SQl Queries, and close the resources like ResultSet, Statement, and Connection.
    Suppose we use the Spring JDBC module to prepare Data Access Layer. In that case, we must take explicit responsibility to write and execute SQL Queries only, not to take any responsibility to load and register driver, connection establishment, creating Statement and closing the resources.
  2. In the case of Plain JDBC, almost all the exceptions are checked exceptions. We have to handle them explicitly by providing some java code.
    In the case of the Spring JDBC module, all the internal checked exceptions are converted into Unchecked Exceptions, which are defined by the Spring DAO module. It is very simple to handle these unchecked Exceptions.
  3. In Plain JDBC, limited support is available for Transactions.
    In Spring JDBC Module, very good support is available for transactions. We may use the Transaction module also to provide transactions.
  4. In Plain JDBC, to hold the results, we can use only the ResultSet object, which is not implementing java.io.Serializable interface, which is not transferable in the network.
    In Spring JDBC, we can get results of SQL Queries in our required form like in the form of RowSet, Collections, etc., which are implementing java.io.Serializable interface and transferable in Network.
  5. In plain JDBC, we can get Connections either by using DriverManager or by using Datasource.
    In Spring JDBC, we can get Connection internally by using Datasource only through Connection Pooling.
  6. In plain JDBC, to map records to Bean objects in the form of Collection Object, we must write java code explicitly. No predefined support is provided by JDBC technology.
    In the case of Spring JDBC, to map Database records to Bean objects in the form of Collection Spring JDBC has provided predefined support in the form of “RowMapper.”
  7. In Plain JDBC, no callback interfaces support is available to create and execute the sql queries in PrfeparedStatement style.
Spring DAO
Scroll to top