2
A
回答
3
当您选择使用依赖注入时,您选择定义抽象,隐藏实现细节。最大的挑战之一是在设计抽象时忽略实现细节。
虽然你可能知道你的HTTP服务会定期轮询是,你并不一定基于上述假设的定义抽象。
试想一下,事情是非常不同的 - 例如,有关的服务可以推送更新到客户端。抽象依然存在吗?
- 如果你建立一个围绕假设抽象客户端是一个Polling Consumer,它可能不太适合,如果你需要实现它上Event-Driven Consumer代替。
- 有趣的是,它更容易模拟与基于轮询技术事件驱动消费者。
即使您从来不希望使用轮询消费者以外的其他任何东西,上述操作仍然是一个很好的练习,因为这会迫使您考虑是否设计了泄漏抽象。
所以,要回答这个问题:更新逻辑属于数据访问实现。
相关问题
- 1. 依赖注入或服务位置?
- 2. 处理依赖注入 - 逻辑走向何处?
- 3. 依赖注入
- 4. 依赖注入
- 5. 依赖注入
- 6. 依赖注入
- 7. 依赖注入
- 8. 依赖注入
- 9. 使用依赖注入来注入依赖注入器
- 10. 服务定位与依赖注入
- 11. 依赖注入Android
- 12. MVP依赖注入
- 13. NServiceBus依赖注入
- 14. WPF依赖注入
- 15. 依赖注入2.17
- 16. 依赖注入`trait`
- 17. MVVM依赖注入
- 18. RESideMenu依赖注入
- 19. AngularJS - 依赖注入
- 20. ui.bootstrap依赖注入
- 21. 依赖注入@protocol?
- 22. Wicket依赖注入
- 23. #botframework依赖注入
- 24. Spring依赖注入
- 25. C#依赖注入
- 26. 依赖注入akka.net
- 27. 依赖注入context.getbeans
- 28. 依赖注入wcf
- 29. Wcf依赖注入
- 30. MVC依赖注入
这一切都有道理。谢谢! – podnov