Can anyone please explain difference between Triggers, Behaviors and Commands. I tried to search on this, but could not find anything useful.
And would also like to know in which scenario which one should be preferred and which one is used frequently among them?
Behavior is a way of interactivity without writing code. Behaviors makes interactivity much simpler for the designers. In short, a behavior is a reusable piece that encapsulates some functionality that can be attached to an object to extend its built-in interactivity capabilities.
Commands are used to encapsulate a piece of logic, which various Silverlight controls can bind to and execute in response to an event, such as a button being clicked. You can expose a command from a ViewModel as a property and bind the Command property of a control in the View to it. When the control is clicked, the command will be executed.
In MVVM scenarios, triggers are used to notifying the view of an event from a ViewModel.
For example, perhaps the view needs to navigate to another view once a save operation is
complete. You can implement this behavior by raising an event from the ViewModel that the view can listen for by doing either of the following:
• Wiring up an event handler in the view’s code-behind and writing some code to
respond to the event (Not recommended approach)
• Implementing a trigger in the view that listens for the event and responds accordingly
You can see this, this and this for more explanations.
Also, Pro Business Applications with Silverlight 5 is a very good reference for you.
Related
I am using the MVVM pattern in my WPF application. In one of my Views I have a button that when clicked uses Commands to talk to its ViewModel. The problem I have is that I need the ViewModel to then talk to other ViewModels to call some of their public methods. I use IOC (Unity) and inject the container into the first ViewModel, so could access the others by using this. I’m not sure if this fits in with the MVVM concept.
Is it possible for all my ViewModels to somehow subscribe to the one button click?
Are any of these the recommended way of solving this problem or is there a better way?
To explain a bit more about my application, each view is a tab control with several textboxes. On the first tab there is also a button and combobox. The user is free to enter their own data or select an option from the combo. In this instance, if the button is then clicked I need all the tabs to load their textboxes based on the selected item in the combo from the first tab. I somehow need to wire this button click in such a way that the value from the combo is passed to all the related viewmodels.
You can use the EventAggregator. Have the command publish an event that the other ViewModels can subscribe to.
When the event is raised they'll all get the event, without needing for one VM to know the other VMs
Another option is to use Composite Commands instead of a regular command.
Make the command the button uses a composite command, and have the other viewmodels register to that Composite command.
You could go a few ways with this one:
use some kind of eventing framework to notify all subscribers if something happens: eg Prism EventAggregator. For this to work you'll need to set up Prism obviously. There are other (MVVM) frameworks out there which support some kind of event/message system like Caliburn.Micro or MVVMLight
Create a MasterViewModel that contains all the child viewmodels for all the tabs. This way the 'master' can subscribe to the PropertyChanged events from its children and execute the appropriate actions. Or the Master can even contain the commands which you are binding to.
I would recommend using some form of "Messenger" service. By this, I mean a class that implements the "Subscription Pattern."
I'm not sure which MVVM library you might be using, but if you look at the "MVVM Light Toolkit" - which is available on CodePlex - you will find a very light implementation of a Messenger there.
Basically each ViewModel will subscribe to receive a specific notification and your ViewModel with the combo box and button will publish the message when the button is clicked. It is really quite flexible in how you send the messages and your ViewModels don't need to know anything about each other.
If you are using the MVVM lite toolkit from GalaSoft you have access to the Messenger which would allow you to send a message that you can subscribe to in each of your view models.
// Send message from command handler
Messenger.Default.Send<MyMessage>(new MyMessage());
// Register for message in view models.
Messenger.Default.Register<MyMessage>(this, MyMessageReceived);
// Method to do work
private void MyMessageReceived(MyMessage myMessage)
{
// Do Work
}
Sometimes a Domain Model object with a business logic (DDD) when calling a method an event is fired.
In my situation, a viewmodel (for a given view) encapsulates the domain object and needs to register and react on those domain events (i must use events because that same domain object can be managed by many loosely coupled views along with their viewmodels).
I also need to unregister to those events when that particular context is hidden.
I can handle this register/unregister/dispose in parallel with show/hide/dispose of that view using databinding, programmatically or whatever if the scenario keeps simple enough...
The problem comes when visualization logic comes with DataTemplates.
How can I know when that datatemplate becomes hidden so that I can unregister my events? is it there a better way with wpf to handle this, instead of adding more events?
What is the best practice to handle this scenario in a good MVVM approach?
edit: ok, the problem is structural. sometimes choices made inside the project has forced us to work in an atypical manner... in a good mvvm approach this problem should not happen
I'd be careful in making the ViewModel dependent on the View for making things right.
So what I would do is provide a property (Show? Visible? Open?) on the ViewModel that has a TwoWay binding with the View so the ViewModel can monitor the property.
What is difference between the two, i am just confused so much on these two concepts and not able to apply correctly?
Attached behaviors is a way of extending controls without having to subclass them! Examples of this is add watermarks to textboxes, forcing textboxes to only accept certain charecters, etc... It is typical stuff that you can do to a control by subscribing to certain events or setting properties! By creating a attached behavior, you are just encapsulating that functionalaty for reuse!
Routed Commands is a way of abstracting away your executing logic for actions like clicking on a button... in WPF, the build in implementation of ICommand, basically walks the visual tree looking for a RoutedCommand that it can execute! The real big diference between these too is that ICommand can only really work on things like buttons... If you need to execute some logic on clicking of a image, you can't without creating a attached behaviour!
Also read up on RelayCommand/DelegateCommand
UPDATE
Attaching a behavior to an object simply means making the object do something that it would not do on its own.
Josh Smith - http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx
In search of a similar question, I came across Chapter 6 of the PRISM 5.0 Handbook, which states as a note on command-enabled controls versus behaviors:
WPF controls that support commands allow you to declaratively hook up a control to a command. These controls will invoke the specified command when the user interacts with the control in a specific way. For example, for a Button control, the command will be invoked when the user clicks the button. This event associated with the command is fixed and cannot be changed.
Behaviors also allow you to hook up a control to a command in a declarative fashion. However, behaviors can be associated with a range of events raised by the control, and they can be used to conditionally invoke an associated command object or a command method in the view model. In other words, behaviors can address many of the same scenarios as command-enabled controls, and they may provide a greater degree of flexibility and control.
You will need to choose when to use command-enabled controls and when to use behaviors, as well as which kind of behavior to use. If you prefer to use a single mechanism to associate controls in the view with functionality in the view model or for consistency, you might consider using behaviors, even for controls that inherently support commands.
If you only need to use command-enabled controls to invoke commands on the view model, and if you are happy with the default events to invoke the command, behaviors may not be required. Similarly, if your developers or UI designers will not be using Blend for Visual Studio 2013, you may favor command-enabled controls (or custom attached behaviors) because of the additional syntax required for Blend behaviors.
For me, this is the single best summary of what’s the difference between behaviors and commands.
I have a 3rd party control which among other things performs loading of some data. I want my viewmodel to keep track of this load operation and adjust its own state accordingly.
If it were up to me, I'd do the data loading far away from the view, but it is not. So, I seem to be in the situation where my viewmodel depends on my view. How do I best handle this? I feel rather dirty making the view publish events to the viewmodel but I don't see any other reasonable way to get this info into the viewmodel.
A similar situation might crop up with standard controls, too - imagine if your viewmodel depends on the events coming from a MediaElement - how do you properly model this? Do you put the MediaElement into the viewmodel? That doesn't sound right.
If publishing the events to the viewmodel is indeed the most reasonable way, is there some common pattern used for this? How do you do it?
Generally, you would not allow your ViewModel to know details or even the type of your view controls. Having it respond to events is the cleaner way to go. There are a number of libraries that contain behaviors to map control events to ICommands on your ViewModel.
Caliburn is one such library. You can map control events to methods on your ViewModel.
My client is trying to hook to a usercontrols Loaded Event in the View Model. Basically they want to know when the controls loaded event triggers inside the view model. They are looking for a way to do it without code behind the xaml. Is this even feasible. I am looking into whether I can route the loaded event to the viewmodel in the xaml.
One way of doing it is to use InvokeDataCommand. You'd specify the trigger's EventName as Loaded, and then your command (defined in your VM) would execute when Loaded event is fired.
You need to look into commanding. Silverlight support is fairly weak compared to WPF but it does contain the ICommand interface. You can extend controls to give them command properties or implement them via an attached property. The commands basically invoke themselves once an action has occurred in the UI. They are totally independent of how the UI is built (or at least they should be) and so can be completely unit tested.