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- *;服务映射到用例和业务流程. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |