将DAO隐藏在服务背后,为什么?

在回顾了大量MVC风格的web应用程序之后,我注意到在业务层前面有一个非常大的服务接口是很常见的。该接口的实现通常包括一组DAO。所以你有这样的想法:

public class FoodServiceImpl implements FoodService {

  private FruitDAO fruitDAO;
  private VegetableDAO vegetableDAO;
  private MeatDAO meatDAO;

  // ... DAO injection stuff

  public List<Meat> getMeat() {
    return meatDAO.getMeat();
  }

  public void addMeat(Meat meat) {
    meatDAO.add(meat);  
  }

  public List<Fruit> getFruit() {
    return fruitDAO.getFruit();
  }

  // ... tons of methods that mostly just delegate to DAOs

}

假设您的DAO一开始不是具体的,为什么不将DAO公开到下一个级别呢?

因此,不是:

// assume foodService is injected at runtime
public void controllerMethod() {
  foodService.getFruit();
  foodService.getMeat();
}

你只是

// assume DAOs are injected at runtime
public void controllerMethod() {
  fruitDAO.getFruit();
  meatDAO.getMeat();
}

一方面,将应用程序的全部内容封装在一个接口中看起来有点不错。。。。另一方面,您可以得到一个巨大的接口,它的实现只不过是委托给DAO。

在启动web应用程序时,这是一种“最佳实践”,还是仅在需要某种程度和类型的复杂性时才适用?