将DAO类与实际在应用程序代码中实例化的DAO类隔离开来有什么好处,即为什么不直接在这样的场景中实例化dao类:
Class CreateIocContainer{
p s v main(String[] args){
new IocContainer("springMetadataFile.xml");
}
}
Class ClassThatInstantiatesServicesViaSpringBean{
Services services;
// bean setter for services class
setServices(Services services){
this.services = services
}
}
Class ServicesImpl implements Services
ServicesDao servicesDao;
String getSomethingFromDB(String argumentForQuery){
return servicesDao.getSomethingFromDB(argumentForQuery);
}
}
Class ServicesDaoImpl implements ServicesDao{
String getSomethingFromDb(String argumentForQuery){
//code to return something from db
return queryResultString;
}
}
此外,我称之为 Class ClassThatInstantiatesServicesViaSpringBean 的类是工厂类,通常命名为 Class XFactory ?
答案 0 :(得分:2)
你的DAO总是接口,它们永远不是一个类。这个DAO基本上是一种设计模式。 DAO及其实现的这种分离为分离对象持久性机制和数据访问逻辑提供了一种很好的技术。
今天在你提到的bean xml文件中,
<bean name="ServiveDao" class="com.example.ServiceImplHibnernate">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
但是明天您可能希望您的应用程序使用您完成的不同实现,而无需更改客户端代码。例如,您已使用ibatis重写了实现,并具有其他功能以满足您的要求。所以你写了一个课
class ServiceImplIBAtis implements ServiceDao {..}
并更改xml文件以加载您的实现
<bean name="ServiveDao" class="com.mycompany.ServiceImplIBAtis">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
在引用bean ServiceDao时,spring将注入ServiceImplIBAtis实例而不是ServiceImplHibnernate。现在您的应用程序不需要知道后台更改了什么。它需要知道的是有一个名为Service的dao,并且有一些方法可用于数据访问。