MVVM – More Lessons Learned from the Trenches

No Code Behind

What no code behind? Is it really a goal for the MVVM to eradicate code behind? Well, in my opinion no and here is why. Currently, MVVM is a talking point for those of us in the developer domain. Some designers are also interested in this development (probably because they do not have to deal with developers anymore in this brave new WPF/Silverlight world) and are looking for what is in it for them. Well as a designer I will want to have some nice transitions packed away in storyboards, etc. Okay, I here you say, that is not in code behind that is in the XAML and you are right. But what if I want to have these nice storyboards triggered on some state change or action. Well now I need some code. Okay, the action can be caught over the datacontext in the View-Model and I can then do something in the View. Wooops, code behind and possibly based on property changes either in the View-Model or the View. Okay, it’s not too much, but it can safely be said that code behind is here to stay. So, lets us define some ground rules; no business, or View-Model, or Model logic in the code-behind, but as much view logic as it takes to make a killer app. Okay?

Preparing for Commands

So we wanted as little code behind as possible, even to eradicate it completely. Well, we had better be prepared for what that means for the View and the View Model. What I currently see in projects and out on the net is basically data-binding oriented. All well and good but what about actions based on user decisions and not just user input? Yes, we can use commands here, anything based on ICommand basically. From the WPF built in commands, through DelegateCommand and all similar extensions, to our own customs commands we have forgotten on big thing – we have still not designed our custom controls or user controls with MVVM in mind.

As an example, we have as developers been asked for some simple search functionality. We have also noticed that we will be “reusing” this functionality throughout the application. Hence we decide upon a simple ccc user control. Excellent, when the user hits the search button the search string will be returned or read and the business logic will take over. To cut to the chase, the finished user control will implement a SearchText as a Dependency Property that returns a string. Moreover the string should be a two-way bindable property where the string can be prefilled if required. The action of searching is obviously an ICommand implemented as a Dependency Property.

Forget all those event handlers that read directly from the TextBox – that might just do, but it is certainly not “Designed for MVVM”.

And no Design Time Support

Even just the basic Design time support makes for a cleaner, more understandable, and more usable control. Justin Angel has shown us the basics, the guys at Microsoft have put the pieces in place and have even been using the framework themselves (quote, reference). And the rest of us? Well we have no time, no budget, no experience – whatever. But this is really just not good enough. Some of our design colleagues do not want to be looking through the Miscellaneous tab in Blend to try and figure just where did the developer put that DP? Oh, no, I still have to enter that name, enum, list value, whatever via a TextBox? Are all the properties first level properties in Blend or can I hide them away until I really need them?

Moreover, are those developers still thinking that the designers must ask when they want some behaviour for a TextBox (mandatory, or Regex for example)? Why have the developers not supplied this functionality as Blend Behavours? Why are the designers not demanding this functionality to be supplied this way?

Really, until the design time has been completed, the control, or the application has not been completed. Well, maybe it has, but you are not going to lever any reuse on what is there.

Conclusion

I remember the good all days when everyone started coding in C++. Those developers that really did understand OO principles just stood there exasperated at those C programmers that wrote C++ as C with classes. And what has really changed? Now we have the new wave of WPF developers, i.e. those WinForm and/or Visual Basic and/or Java developers that are now writing WPF/Silverlight applications as WinForms with XAML. Yes, I should have seen it coming…..

I really suppose I should go through a simple example that brings the above topics together – maybe I should start writing the blog topic right now…..

That’s all folks…

~ by Intelligence4 on January 7, 2011.