What is the proper/best way to fix this? I believe you could add a CurrentItemURI property to the MainViewModel class and update and bind to that instead of the URI property. Alternatively, you could bind to FeedViewModel.SelectedFeedItem.Link (and not update the URI property).

Thanks,

Rob

As for MVVM being an architectural pattern, that’s pretty well established. Even look at Wikipedia: http://en.wikipedia.org/wiki/Model_View_ViewModel …

Thanks

MVVM is not just about the presentation layer – it’s the overall architectural pattern.

The “Model” in MVVM is the same core model that’s holding your domain/business logic. The ViewModel is where you’d put any application specific bridge code that’s required. It’s purpose is to take your Model and expose it to your presentation layer (View).

One of the main goals with MVVM is to keep the “Model” pure – you should be able to use your direct business logic and domain data without change. The ViewModel is where you place the code required to adapt your model for presentation.

-Reed

Best Regards,
Rohit

If you’re working on code that interacts with your business logic, and is specific to your application at hand, MVVM is appropriate.

If you’re making a reusable control that’s intended to be used within the View layer from any application, your code is really “pure View” related, and MVVM doesn’t really apply. In this case, there is no Model, which means a ViewModel doesn’t make sense (its purpose is to bridge between the View layer and your Model).

The same is true in Windows Forms – When writing a custom control, you don’t necessarily think in terms of architectural patterns like MVP, but rather making a single, reusable component.

Only Microsoft could have come up with such a Unified Model that makes so much sense.

When making your Gauge control, you really shouldn’t be thinking MVVM – it doesn’t apply when writing a control, as you’re writing pure view code. I’d use code behind here – I wouldn’t do IValueConverters for writing a control, but rather reusable ones for writing an *application that uses the control*. When writing a control, you’re pure View, and you’re really completely outside of where MVVM applies…

-Reed

Also, implementing 50 or more IValueConverters, once again in code, proves cumbersome to say the least, when doing all these calculations in a loop in one method, say on a ControlLoaded event, seems the most efficient implementation. Never mind easier to follow and maintain. (I also don’t see any way of looping in XAML. For example, draw a Border ‘n’ times).

So what exactly “fits” the MVVM model here when 95% of doing this GUI is in code? How is declaring the View (GUI stuff) in XAML supposed to make these things easier for a development team?

–Bill

There are actually two issues here.

For the first – the gauge control – I’d actually argue that this, being a control, is entirely, 100% View. Custom controls really fall outside of the realm of MVVM entirely, as they’re a resource that will be used later to implement the View in MVVM. I would, personally, actually use code behind to implement a custom control such as this, as it’s far simpler than trying to separate this out in many cases.

Now – your second – the sizing situations example. This, to me, seems like a perfect case for a custom IValueConverter. The advatange here is you can make a converter to handle sizing, and reuse the converter in XAML with various values (ie: different sizing ratios) whenever needed.

In my opinion, this fits in MVVM perfectly – you’re writing code, but the code is a reusable block of code (unrelated to your domain/application specifically) that can be reused as needed throughout your application. The code isn’t “domain specific logic”, but rather some additional functionality that can be used by any View, in any application.

-Reed

Take a simple Circular Gauge Control I made in Silverlight (dstechlabs.com/cc). The font sizes I choose are directly proportional to the Diameter (DependencyProperty) of the gauge. And the placement of other child components are also mathematically related to Diameter. And if I use IConverters for all these placements, then I’m doing these calculations in code anyway, not XAML.

Also, the short and long ticks at the edge of the gauge are made by looping thru angles and using trig functions to get their endpoints. Also, the number of ticks (the step size between angles) is proportional to Diameter.

There just seems to be too many situations where sizing decisions can’t be made in XAML. For example, suppose I want a TextBox to be 3 times the width of the text rendered in a TextBlock. I don’t know this size until it’s rendered.

I guess I’m missing something in my understanding of WPF’s View.
Thanks for shedding any light on this for me.

–Bill Daniels

I haven’t blogged much about MEF + MVVM, other than this: http://reedcopsey.com/2010/03/26/mef-compositioninitializer-for-wpf/

That being said, most posts that are about Silverlight apply to WPF as well.

-Reed

Excellent work! As a beginner I was looking for some good tutorial on WPF-MVVM and stumled upon your blog….lucky me!! Your series really helped me in understanding basic concept of this framework and architecture pattern.

One question: Do you have similar series/example for using MEF with a WPF-MVVM application? If so it would be really greate if you can share!

Keep up the good work!!

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