What’s the difference?

What is the difference between typical WPF/Winforms applications which do not incorporate the MVVM pattern and those that do?

Should the view be responsible for obtaining the data?

How many axis’s of change are there here?**

• Ok we have the customer who wants to see the view a different way. If we have two sets of customers then that’s two sources of change. So they cannot use exactly the same code, because if a customer requests a change in one view, it will inadvertently affect how the other customer views her data. So at the very minimum, we have one axis of change.

• What about the collection of the data? That might be handled by our database administrator. What if he wants to change the method/mode of data collection? That means in order to do so, he will have to change the View class – which serves a completely different master – the view class looks after the users who want to see their data in a certain way. There is a possibility that the database administrator will make a change that will inadvertently affect how things look. If the DB admin decides, for example, to switch from PostgreSQL to MySQL then we shouldn’t see any change in the view.

• The MVVM design pattern seeks to minimise the links between the obtaining of the data/information from the actual displaying of the data/information. Of course, the two are still coupled together to a certain extent. If you decide to change the data types, then you will necessarily have to change what is displayed. But we have minimised, to a certain extent the coupling which exists between the two.

Summary

• Fundamentally, MVVM pattern minimises the views reliance/obligation on obtaining data, and/or interacting with the “model” directly. There is still some coupling, but less so.
• Changes in the collating of data can now be made without affecting the view.