为什么要在服务背后隐藏DAOs？

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();
}

一方面，将应用程序的整个内部包装在一个界面中看起来很不错……另一方面，您可能会得到一个巨大的接口，其实现除了委托给DAOs之外，什么也做不了。

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

在启动web应用程序时，这是否被认为是“最佳实践”，或者它是否仅适用于预期的特定级别和类型的复杂性？

Answer 1

我认为注入服务层更有意义，因为它知道工作单元。如果您的用例需要多个DAO参与一个工作单元，则需要一个服务来“拥有”事务。

此外，它也是面向服务架构的精髓。忘记WS-*；服务映射到用例和业务流程。

Answer 2

假设整个后端不只是一个巨大的CRUD API，您将经常看到在服务层调用的业务逻辑。业务逻辑可能直接在服务方法本身中(也称为。“贫血域模型”)或服务层必须只负责调用传递到DAO层/来自DAO层的实体上的业务方法(“富领域模型”)。您可能还会看到诸如安全性或审计之类的事情在服务层中完成。或者，诸如安全性或审计之类的横切关注点可以通过面向方面编程(AOP)应用于服务层。

Answer 3

创建一个类只有一个原因:将实现的一些细节隐藏在固定的边界之后。在本例中，您有一个名为FoodService的服务，以及一个知道各种DAO的实现类。那你到底在隐藏什么？

它看起来像两件事：

你有那些食物种类的事实，

2. 它们的储存方式。

如果它们的存储方式永远不会改变，那么您可能不需要这样做。但是，如果您的DAO曾经被一种不同的机制所取代--比如一个分布式的谷歌BigTable --您可能更喜欢不需要修改所有代码的类型。

当然，您总是有可能开始使用HealthAndBeautyAids，因此需要另一个类。(实际上，如果有一个方法告诉您可以访问哪些类型的对象，然后让方法访问给定类型的对象，这样不是更好吗？)