加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > Java > 正文

java – 隐藏DAO服务,为什么?

发布时间:2020-12-15 05:18:46 所属栏目:Java 来源:网络整理
导读:回顾一堆MVC风格的Web应用程序后,我注意到在业务层前面有一个非常大的服务接口是很常见的.该接口的实现通常包括一堆DAO.所以你有类似的东西: public class FoodServiceImpl implements FoodService { private FruitDAO fruitDAO; private VegetableDAO vege
回顾一堆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应用程序时被视为“最佳实践”,还是仅在预期某种程度和类型的复杂性时才适用?

解决方法

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

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

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读