and see the following business Layer implementation class sample code:
public class Userserviceimpl implements UserService {
Private Userdao Userdao;
public void Setuserdao (Userdao Userdao) {
This.userdao=userdao;
}
public void Saveuser (user user) {
if (Userdao.findbyid (User.getid ()) ==null)
Userdao.save (user);
}
...
}
Problem:
1. Why does the Userdao Interface not declare a specific implementation class, and the method in the Userdao interface can be called in the saveuser method ?
The business layer invokes the underlying implementation through the interface, and the specific DAO Implementation class does not appear in our business code, but is configured in the configuration file, which is the Spring Framework in the control reversal (IOC and Dependency injection (DI) Thinking in a technical implementation mechanism, we can see that the applicationcontent.xml configuration file has the following configuration code:
<!--Configure the data persistence layer to inject DAO into the session factory--
<bean id= "Userdao" class= "Com.integration.dao.UserDAOImpl" abstract= "false" lazy-init= "Default" autowire= " Default ">
<property name= "sessionfactory" ><ref bean= "Sessionfactory"/></property>
</bean>
2. Why not directly instantiate a specific implementation class object for the business layer to invoke, but through the interface to implement?
We know that the method declared in the interface can be implemented in many different implementations of the interface method, such as different database access operations, may be corresponding to a number of unnecessary implementation classes, if a project in the subsequent maintenance needs to change the database type, then just add an implementation class, You can then modify the implementation class name in the configuration file so that you do not have to open the original Java file rewrite, which facilitates later maintenance of the project.
Why use this design approach to interfaces, and what are the benefits?