Menu
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.
819
The viewmodel of MVVM is a value converter, meaning the viewmodel is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented. In this respect, the viewmodel is more model than view, and handles most if not all of the view's display logic.
The ViewModel is the centerpiece of MVVM. It has all the business logic and some of the display logic in it. The ViewModel needs to adapt the information in the Model for the Views to display. The ViewModel also transforms input events into data for the Model to store.
Model-View-ViewModel (MVVM) is a structural design pattern that separates objects into three distinct groups: Models hold application data. They're usually structs or simple classes. Views display visual elements and controls on the screen.
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.
56
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:
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.
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.
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.
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.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
