隐藏DAO服务,为什么？

Question

回顾一堆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.

我可以看到在一个地方管理所有DAO很好.我还可以想象,如果要通过多种服务使用相同的DAO,这种模式将非常有用.

这在启动Web应用程序时被视为"最佳实践",还是仅在预期某种程度和类型的复杂性时才适用？

Answer 1

我认为注入服务层更有意义,因为它知道工作单元.如果您的用例需要多个DAO参与一个工作单元,则需要一项服务来"拥有"该交易.

此外,它是面向服务架构的本质.忘记WS-*; 服务映射到用例和业务流程.

Answer 2

假设整个后端不仅仅是一个巨大的CRUD API,您通常会在服务层中看到调用的业务逻辑.业务逻辑可能直接在服务方法本身(又名"Anemic Domain Model")中,或者服务层必须只负责调用传递给DAO层/从DAO层传递的实体的业务方法("Rich Domain Model").您可能还会在服务层中看到安全性或审计等内容.或者,可以通过面向方面编程(AOP)将诸如安全性或审计之类的横切关注点应用于服务层.