存储库设计模式指南
假设您有一个 MVVM CRM 应用程序。
您通过存储库在内存中拥有许多客户对象。
哪里是处理与 GUI 中的传统 MVVM 任务无关的任务的合适位置？
例如，假设每隔几分钟您想要检查他们的地址是否有效，如果无效则弹出通知。或者您想发送每小时更新的电子邮件。或者您希望弹出一个窗口来提醒您在特定时间致电客户。
这个逻辑去哪儿了？我认为，它不是面向 GUI/操作的，也不是适合存储库的逻辑。
Let's say you have an MVVM CRM application.
You have a number of customer objects in memory, through a repository.
What would be the appropriate place to handle tasks that aren't associated with traditional MVVM tasks from a GUI?
For example, let's say every few minutes you want to check to see if their address is valid and pop up a notification if it is not. Or you want to send out an hourly e-mail update. Or you want a window to pop up to remind you to call a customer at a specific time.
Where does this logic go? It's not GUI/action-oriented, and it's not logic that would be appropriate for a repository, I think.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您要问的是，“我的 MVVM 实现应该如何处理不是用户输入直接结果的 GUI 相关任务？” （如果我误解了您，请告诉我。）
您描述的任务很可能是由计时器协调的。如果将计时器的滴答声定义为“用户操作”，那么它与传统的命令模型并没有真正的区别。
这意味着视图模型将管理计时器并更新自身作为响应。当应向用户显示通知时，它可以设置一个属性，并且视图可以响应该属性中的更改并显示弹出窗口。重要的概念是视图模型仍然负责协调行为，而视图只是反映视图模型的当前状态。
（每小时电子邮件更新不是与 GUI 相关的任务，因为它不与用户交互；我将其排除在外。）
至于实现定时行为的对象，@epitka 提出了通过描述服务的概念来明确要点。通常，服务协调多个存储库或其他服务之间的行为。它们代表不能分配给任何一个特定实体的特定于域的逻辑。
I think what you are asking is, "How should my MVVM implementation handle GUI-related tasks that are not a direct result of user input?" (Let me know if I have misinterpreted you.)
The tasks you describe are most likely coordinated by a timer. If you frame the timer's tick as a "user action", then it isn't really different from the traditional commanding model.
This means a view model would manage the timer and update itself in response. It may set a property when a notification should be shown to the user, and the view could respond to the change in that property and show the popup. The important concept is that the view model is still responsible for coordinating the behavior, and the view simply reflects the current state of the view model.
(The hourly email update is not a GUI-related task, in the sense that it doesn't interact with the user; I left that one out of the mix.)
As for the objects which implement the timed behavior, @epitka hit the nail on the head by describing the concept of a service. Generally, services coordinate behavior across multiple repositories or other services. They represent the domain-specific logic that can't be assigned to any one particular entity.