依赖注入刷新逻辑位置
我对这里的依赖注入完全陌生。
如果我正在使用依赖注入构建 Twitter 客户端，那么控制以特定时间间隔（例如 5 分钟）刷新流的逻辑应该放置在哪里？
I'm completely new to dependency injection here.
If I were building say a twitter client using dependency injection, where should the logic that controls refreshing my stream at a specific interval (say 5 minutes) be housed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您选择使用依赖注入时，您选择定义隐藏实现细节的抽象。最大的挑战之一是在设计抽象时忘记实现细节。
虽然您可能知道您将定期轮询 HTTP 服务，但您不必根据该假设来定义抽象。
想象一下，情况有很大不同 - 例如，相关服务可以将更新推送给客户端。抽象仍然成立吗？
即使您从未期望使用轮询消费者以外的任何其他东西，上面的内容仍然是一个很好的练习，因为它迫使您考虑是否设计了一个有漏洞的抽象。
因此，回答这个问题：刷新逻辑属于数据访问实现。
When you choose to use Dependency Injection, you choose to define abstractions that hide away implementation details. One of the biggest challenges is to forget about the implementation details while designing the abstractions.
While you may know that you'll be polling an HTTP service regularly, you shouldn't necessarily define your abstractions based on that assumption.
Imagine that things are very much different - for example that the service in question could push updates to the client. Would the abstraction still hold?
Even if you never expect to use anything else than a Polling Consumer, the above is still a good exercise to do, because it forces you to consider whether or not you've designed a leaky abstraction.
So, to answer the question: the refresh logic belongs in the data access implementation.