MVVM defined from a Business Workflow perspective

In software engineering we have what are called Design Patterns. Most tech interviews have at least one question on a pattern called Model View Controller, or MVC. You can do a search and come up with millions of results, but basically your business model and the view presented to the user are two separate systems glued together by a Controller that watches for changes in the Model and listens to events in the View.

As patterns have evolved since the original work written by the "Gang of Four", another flavor of UI design has arisen called Model View View-Model, or MVVM. It's exactly the same thing, only different-- in this case your controller is replaced by a view-model. Huh? Why not just call it a controller?? People make arguments about the subtle differences between MVC, MVP, MVVM, and MV*, but it's all pretty much just to confuse people in interviews.

I like to think of it in terms of business processes, and the workflows that support them. A business process could be something like "providing a way for people to sign up." Workflows to support that process could include:

• Providing a signup page for people to enter their information directly.
• A referral page so that some of the person's information is already filled in by another member.
• Admin screens for customer service reps to complete the process on behalf of the user.

The business process has specific requirements, like having a username and a password. Maybe an email address or phone number, too. But as people are going through the individual workflows they might need to leave those things blank because they haven't come up yet. That's where the view-model comes in. It stores the workflow-specific information relevant to that data entry screen, and provides a mechanism to pump the important information into the business process once it's ready.