CODEWITHSUNDEEP
wpfdesign-patternsmvvm
tbfa
tbfa

Reputation: 509

Repository Design Pattern Guidance

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.

Upvotes: 3

Views: 492

Answers (1)

Bryan Watts
Bryan Watts

Reputation: 45465

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.

Upvotes: 1

Related Questions