How do Behaviors and ViewModels relate in MVVM?

Question

So I stumbled upon a problem while learning MVVM. I had a TreeView that contained TextBlocks which I wanted to perform an action on when I double clicked any of the TextBlocks in the TreeView. I started to learn about Behaviors, and I have a great example of how a behavior is implemented but the example does not connect the Behavior to a ViewModel at all. So in other words, if I double click on the TextBlock, I have the Behavior class that catches it but I don't have any ViewModel to perform any actions.

Could someone take a moment and explain how these tie in? I was reviewing this article: http://msdn.microsoft.com/en-us/library/gg430869(v=pandp.40).aspx But I didn't seem to grasp what I was looking for.

Bawdy

Answer 1

MVVM concept provide us a decoupling mechanism in WPF application which means no more code in xaml.cs file. Attached behavior is different thing. It has not relation with MVVM.

But because if we have scenarios where I cant use MVVM e.g. Select the text of TextBox on double click. Which is a behavior you want to add on textbox.

You will prefer implement the double click functionality in xaml.cs file as it not reusable and also tightly coupled.

This is where behavior come into picture. We will create the behavior for TextBox and will attach it. Now you can attach this behavior to as many controls you want.

EDIT:

if you are using WPF 4.5. you can look Markup Extensions for events

If you want to do it with attached behavior. Create an attached behavior of double click event which has Command dependency property. Your double click behavior just raise the command attached and in xaml bind the command with viewmodel which I expect you know how.

Hope, I am able to answer you comment.

Roesch

D J - Does the Behavior class I create not have any relationship to the ViewModel itself? So take for example I have a TreeView and when I double click a Node in the TreeView I want to delete that node. When I catch the DoubleClickEvent in the Behavior class, I have no access to the ItemsSource in the TreeView (stored over in the ViewModel). – Bawdy

Answer 2

D J has a good answer, though I'd like to insert some additional thoughts to this discussion.

In my experience, view behaviors (whether code-behind, attached behaviors, blend behaviors, or custom control logic) are often useful when the view does not depend on a view-model to function properly. If a view (UserControl, Window, Page, etc.) does not logically make sense in the absence of a view-model, it might make more sense to remove behavior from the view and move it to the view-model.

While we can do pretty much anything under the sun with all types of behaviors, it is often not wise to. MVVM, for good reason, limits what we should do so that we can observe separation of concerns to improve our application's cohesiveness and to decouple our classes. These two things are what software maintainability is all about, and these concepts become increasingly important as the application grows into enterprise software.

It is important to think about the concerns that the behavior has. Understanding this will help us find a properly suited place for it. Here are some questions to help know where it belongs:

Does the behavior interact with a business domain model (this is the first 'M' in MVVM)?

Behavior that has a dependency (even a loosely coupled one) on a domain model should likely belong in the view-model (or service), and not in the view. For instance, if the behavior needs to save to or read from an external device (e.g. a database), it has a dependency that the view should never have. Wrap this logic in a service function. Or if not using a heavily layered architecture, put this inside of a view-model.

Does the behavior interact with application services, domain services, infrastructure services, etc.?

For the same reasons as the prior answer, the behavior likely belongs in the view-model or a service class. The view should have no explicit knowledge of services or domain model objects as it would muddy up its responsibilities (or concerns) that the view has. A view should only be concerned the visual/physical aspect of the user UI. Many views should define a contract (i.e. a view-model interface) that it binds to in order to operate correctly.

Will the behavior need to be reused across different views of the same kind?

This is a bit of a tricky question. Many times we foresee being able to have a different presentation for the same content. In effect, the view in these cases is a thin wrapper around some structure. For instance, suppose for a e-mail application we have a summarized view for received e-mails as well as a detailed view. Both views might need to support the same behavior (e.g. delete, reply, forward). Because we are reusing the behavior across different views of the same kind, then the behavior should belong in a common, reusable place. View-model logic is a good place for this.

Will the behavior need to be reused across views of different kinds?

When the behavior needs to be reused across different kinds of views (e.g. TextBox, ComboBox), we likely need an attached behavior. Usually, we can know this because the views are so diverse that it is not possible for them to share a view-model interface. Given that the behavior is concerned with view-related responsibilities, then custom control logic, code-behind, attached behaviors, or blend behaviors are all suitable places.

Seminarian