The data access layer works as an aspect between the business layer and the database. Data accessing depends on the business call, and it varies depending on the source of the data for example database, flat files, XML, and so on. So, we can abstract all access by providing an interface. This is known as the data access object pattern. From the application's point of view, it makes no difference when it accesses a relational database or parses XML files using a DAO.

In an earlier version, EJB provided entity beans managed by the container; they were distributed, secure, and transactional components. These beans were very transparent to the client, that is, for the service layer in the application, they had automatic persistence without the care of underlying database. But mostly, the features offered by these entity beans were not required for your application, as you needed to persist data to the database. Due to this, some non-required features of the entity beans, like network traffic, increased, and your application's performance was impacted. And that time, the entity beans needed to run inside the EJB containers, which is why it was very difficult to test.

In a nutshell, if you are working with the traditional JDBC API or earlier EJB versions, you will face the following problems in your application:

• In a traditional JDBC application, you merge the business tier logic with persistence logic.
• The Persistence tier or DAO layer is not consistent for the service layer or business tier. But DAO should be consistent for the service layer in an enterprise application.
• In a traditional JDBC application, you have to handle a lot of boilerplate code like making and closing connection, preparing statement, handling exceptions, and so on. It degrades reusability and increases development time.
• With EJB, the entity bean was created as an overhead to the application, and was difficult to test.

Let's see how spring solves these problems.