The approach of these authors reflects the reality that a) there is more than one way to do MVVM, and b) you should not attempt to build a serious MVVM app without the aid of a toolkit. The problem is that, if you are coming up to speed on MVVM, learning the ins and outs of a particular toolkit can be daunting…
…
Rather than shying away from some of the more controversial aspects of MVVM, I’ve decided as much as possible to address them directly. Much of it boils down to your needs and preferences. A good example is going for zero (or almost zero) code-behind. That might be a laudable goal if you have a team of visual designers using Blend that must be able to work independently from developers. I’ve found, however, that many shops have developers building the UI. In this case, achieving zero code-behind results in greater complexity and lowers developer productivity. …
Another topic where there are diverging opinions is on how to communicate between various components, such as between the view and view-model or among view-models. One approach is to use a message bus of some sort. While that does make sense in many scenarios, especially communicating among view-models, I felt that a simpler approach using events is more practical and easier to use. …
Another area where there are different approaches concerns the use of commands. Many MVVM toolkits include a delegating command which is used by the view-model to expose a command property that an element such as a button can bind to, so that the click event results in calling a method wired up to the command. My personal feeling is that using commands for every button click (or other events by means of an event-to-command behavior) requires a lot of extra code in the view-model that is basically unnecessary. …
Read more: Greg's Cool [Insert Clever Name] of the Day
Posts
