What Exactly is a View

1. What Exactly is a View-Model? After being introduced to the term “view-model,” many developers are left with more questions than answers. While it is clear that view-models need to deal with the junction between views, models, and external services, the exact approach is often glossed over. And with no clear list of what should, or should not, be in the view-models, they often end up being a dumping ground for everything. While this article does not claim to offer a definitive answer, it does explore some of the many roles assumed by the view-model. As you read through the various roles and patterns, please these keep three things in mind:    I have seen each of these examples used in a real project. Most view-models are going to assume multiple roles. Exact adherence to a pattern isn’t as important as a working application. Model-Side Roles offering data to the views is an essential role of the view-model. However, there are many different ways data can be offered while still using XAML’s data binding technology. View-Model as a Surrogate Data Context This is the simplest and probably most common version of the model-side patterns. Here, the view-model acts as a surrogate data context. The real data is exposed by the view-model as one or more simple properties. In a way, this is a non-pattern. It only exists so the view-model can be associated with the view’s real data context property and inject other functionality such as I Commands that wrap navigation or service calls. We’ll return to this topic later in the article. View-Model as an Active Record An unfortunately common mistake is the “View-Model as an Active Record” pattern. With this pattern there are no true models in the application. Instead, all the fields are offered directly by the view-model itself. For example, the Customer View Model would have fields such as First Name, Last Name, and Customer ID. Since this is a view-model, it will most likely have external service hooks as well. These would be exposed as Commands such as Load Customer Command and Save Customer Command, effectively turning the view-model into an Active Record. It should be noted that the Active Record pattern itself can be quite effective under some circumstances. The real problem is that active records are already somewhat bloated and asking them to also deal with the other roles of a view-model quickly pushes them into “god object” territory. As you can see from the diagram, there is no good place to attach unit tests. You can create a fake unit test by supplying an integration test with a mock service, but such workarounds tend to be very time consuming and error prone. For more information Click Here Contact us: 9989971070