throw new DBException(sqle);
}
try{
if (conn != null){
conn.close();
}
}
catch (SQLException sqle){
throw new DBException(sqle);
}
}//end of finally block
return empList;
}//end method findBySalaryRange
}
上面的清单说明了DAO方法的一些要点：
它们封装了所有与JDBC API的交互。如果使用像Kodo或者Hibernate的O/R映射方案，则DAO类可以将这些产品的私有API打包。 ![]() ![]() ![]() ![]()
![]() ![]() ![]() ![]()
它们将检索到的数据打包到一个与JDBC API无关的传输对象中，然后将其返回给业务层作进一步处理。
它们实质上是无状态的。唯一的目的是访问并更改业务对象的持久数据。
在这个过程中，它们像SQLException一样捕获任何底层JDBC API或数据库报告的错误（例如，数据库不可用、错误的SQL句法）。DAO对象再次使用一个与JDBC无关的自定义运行时异常类DBException，通知业务对象这些错误。
它们像Connection和PreparedStatement对象那样，将数据库资源释放回池中，并在使用完ResultSet游标之后，将其所占用的内存释放。
因此，DAO层将底层的数据访问API抽象化，为业务层提供了一致的数据访问API.
构建DAO工厂
DAO工厂是典型的工厂设计模式实现，用于为业务对象创建和提供具体的DAO实现。业务对象使用DAO接口，而不用了解实现类的具体情况。DAO工厂带来的依赖反转（dependency inversion）提供了极大的灵活性。只要DAO接口建立的约定未改变，那么很容易改变DAO实现（例如，从straight JDBC实现到基于Kodo的O/R映射），同时又不影响客户的业务对象：
public class DAOFactory {
private static DAOFactory daoFac;
static{
daoFac = new DAOFactory();
}
private DAOFactory(){}
public DAOFactory getInstance(){
return daoFac;
}
public IEmployeeDAO getEmployeeDAO(){
return new EmployeeDAOImpl();
}
}
与业务组件的协作
现在该了解DAO怎样适应更复杂的情形。如前几节所述，DAO与业务层组件协作获取和更改持久业务数据。下面的清单展示了业务服务组件及其与DAO层的交互：
public class EmployeeBusinessServiceImpl implements
IEmployeeBusinessService {
public List getEmployeesWithinSalaryRange(Map salaryMap){
IEmployeeDAO empDAO = DAOFactory.getInstance()
上一篇:实战角度比较EJB2和EJB3的异同
下一篇:实战角度比较EJB2和EJB3的架构异同
|
精品推荐