- DAO [Data Access Object], it is a design pattern, it able to provide very good environment to separate Data Access logic from Business Processing logic.
- In enterprise Applications, to prepare Data Access Layer we will use DAO Design pattern.
Advantages of DAOs in Enterprise Applications
- We are able to hide all data access implementation from Business/ Service Layer.
- It is very simple to switch data access layer from one data access tech to anther data access tech. without giving any effect to Service/Business Layer, that is from JDBC to Hibernate etc.
- DAOs are able to provide centralized Data Access in enterprise Application, it simplifies the maintenance of Enterprise Applications.
- While preparing Service/Business layer Code Simplification is possible, that is, it is very simple to prepare Service/Business layer.
- We are able get Standardization to prepare Data Access layer with DAOs.
Drawbacks with DAOs
- It adds one more layer to enterprise Application, may get maintenance problems.
- Along with DAOs, we have to implement some 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: 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 are providing single instances of DAO to the service layer, if DAO is required in multiple modules then it is requyired to create more than one DAO reference.
6. In case of DAOs, it is suggestible to interact with Databases by using Connection Pooling mechanisms, not by using DriverManager approach.
7. DAO is not thread safe; we must not use DAOs in multi-threaded environment.
8. In DAOs we can access close() method in order to close the resources like connections so here, before calling close() method we must ensure that whether the resources are going to be released or not with our close() method call.
9. We have make sure that all the objects which are used by DAOs are following Java bean conventions or not.
To provide support for DAOs kind of implementations in Spring Applications, Spring has provided a separate module called as “Spring DAO”. Spring DAO modules has provided a set of predefined classes and interfaces in order 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 no 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 then we must take explicit responsibility to prepare the steps load and register the driver, Establish Connection, creating Statement, executing SQl Queries and closing the resources like ResultSet, Statement and Connection.
If we use Spring JDBC module to prepare Data Access Layer, 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 case of Plain JDBC, almost all the exceptions are checked exceptions, we have to handle them explicitly by providing some java code.
In case of Spring JDBC module, all the internal checked exceptions are converted into Unchecked Exceptions which are defined by 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 Transaction module also to provide transactions.
4. In Plain JDBC, to hold the results we are able to use only ResultSet object, which is not implementing java.io.Serializable interface, which is not transferable in network.
In Spring JDBC, we are able to 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 which are transferable in Network.
5. In plain JDBC, we are able to get Connections either by using DriverManager or by using Datasource.
In Spring JDBC, we are able to get Connection internally by using Datasource only, that is through Connection Pooling only.
6. In plain JDBC, to map records to Bean objects in the form of Collection Object we have to write java code explicitly, no predefined support is provided by JDBC tech.
In 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.