If you’ve made a decision to start using the Model-View-ViewModel pattern (abbreviated as MVVM) for Silverlight development, you’re faced with a rather steep learning curve and a scarcity of of accepted standards and best practices. I’ve read no less than three Silverlight books. All of them have a chapter on MVVM, in which the pattern is explained and some fairly basic examples are provided. But when it comes to taking on some controversial issues, such as how to display modal dialogs, they tend to sidestep the issue and recommend that you pick up an MVVM toolkit. 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
Subscribe to:
Post Comments (Atom)
Posts
0 comments:
Post a Comment