Thanks for the reply, but I can not open the link in my country. Would you please copy the text, and send it to my mail box?

Here’s an article describing one approach. Using SelectedItems is tricky, though.

http://bit.ly/alNF72

-Reed

Very good point re: Silverlight vs. WPF. I definitely see how the limitations in Silverlight, especially prior to SL 4, would make it so having View related code is “less bad” than the alternative hoops you’d have to jump through to avoid it.

Mostly, my goal here was to get people coming from Windows Forms (ie: writing desktop apps) to think differently, so I’m really focused on WPF over Silverlight. I’m trying to explain the why behind the pattern, as well as what specifically makes it work in WPF. It’s something I feel has been lacking in all of the (very excellent) MVVM articles I’ve read to date… For a Windows Forms developer, putting code in the code behind is natural – trying to break that habit is probably the most important hurdle to jump through in moving to WPF, in my opinion.

Thanks for the feedback! I really appreciate it.

-Reed

I love this series, BTW.

On file dialog: One test I have mentally for what belongs in a viewmodel is “if I changed view technology, would it still apply”. I agree that a services is probably a better approach there.

Many Silverlight folks look to WPF thought leaders for information on patterns like MVVM. Until very recently, they had to do things differently due to limitations in the platform. Often times, that meant some small amount of wire-up code in the code-behind. I agree that in WPF it’s harder to justify since the platform is more complete.

Pete

First off, I was suggesting that the goal should be to have zero code in the code behind – not necessarily that it is an absolute, hard rule.

That being said, I do agree that there are times when it’s reasonable to have code in the code-behind. However, in my experience to date, I’ve yet to find a single instance where there wasn’t a more elegant approach. Typically, I’ve found that, when I need code in the code behind file, it’s nearly always handled more elegantly, and more reusably, by creating an attached property or (Expression Blend SDK-based) Behavior, or by using some form of dependency injection/service (I use MEF for this) to handle the creation from within the ViewModel.

Personally, I think displaying a FileDialog is a function of the ViewModel – not because of the dialog (which I agree is View, but could easily be provided via a service), but because the processing of a file dialog is logic that needs to be tested, and having that as part of a command or a method in the ViewModel makes testing much simpler.

Anyways, thank you very much for your comments!

-Reed

“The user interface should be declared entirely in XAML, with zero code behind.”

While I agree that one should keep most logic out of the code-behind, I disagree that there should be zero code there.

View-specific code is ok to have there. That is, code that exists solely to perform a view function, such as building an animation or something, or setting up a relationship between two elements in a view when perhaps that is cumbersome to do in xaml, can be in the view.

Putting something into a specific visual state in response to a message from the VM is, perhaps, another case. Typically (99%) you’d handle that with binding, but that’s not always a reasonable route to take.

Other view code could be for things like displaying a file dialog. Displaying a file dialog is really a view function. Dealing with the results of the dialog should happen elsewhere. If not displayed there, you’re stuck doing something like displaying UI from the ViewModel, which is equally bad, if not worse, than having code in the view.

In practice, most apps will not need code in the code-behind, and most code folks are tempted to put there really shouldn’t be there, but I’d rather not be dogmatic about it

Pete

[WORDPRESS HASHCASH] The comment’s server IP (208.74.66.43) doesn’t match the comment’s URL host IP (74.112.128.10) and so is spam.