Should I mutate the parameter passed to the Execute method on ICommand? If not, what is the best way to change the State of the application, or View Model, after a command is invoked?
Thoughts
The Command Pattern invokes a method on an object, in the case of WPF it's the model or view model. This requires the model to know how to perform the action on itself. We've all seen and used the RelayCommand implementation. The problem I have with this is that it's difficult to swap out behaviors. It's also difficult to find a place to put that "special case" code. What if I want to show another view?
I like the idea of creating a Command for each Use Case. I would have a concrete class that implements ICommand that handles the logic for executing the use case. This requires a reference to the model just like the Command Pattern. The difference is that the action logic would be outside of the model and thus be mutating the model passed in as a parameter. Let's look at some sample code.
I have a window that shows a list of the ubiquitous Person object. We want to invoke a command on a Person that clears their name. MainViewModel has a collection of Person objects called People.
<Window.Resources>
<commands:ClearNameCommand x:Key="ClearNameCommand"/>
</Window.Resources>
<Window.DataContext>
<local:MainViewModel/>
</Window.DataContext>
Here is my list box that is bound to the collection and displays each person with a button to clear their name.
<ListBox ItemsSource="{Binding People}">
<ListBox.ItemTemplate>
<DataTemplate>
<StackPanel Orientation="Horizontal">
<TextBlock Text="Name" Width="100"/>
<TextBox Text="{Binding Name}" Width="100"/>
<Button Command="{StaticResource ClearNameCommand}" CommandParameter="{Binding}" Content="Clear"/>
</StackPanel>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
Below is the Execute method on the concrete class ClearNameCommand. It displays a dialog box asking if they want to perform the action. I think this proves as a good example of why you wouldn't put this command in the model. Also imagine that you had to log somewhere that the name was cleared? Undo Redo maybe?? Where does all this code go??!!
public void Execute(object parameter)
{
Person p = parameter as Person;
if (p != null)
{
if (MessageBox.Show(
"Are you sure you want to clear the name?",
"Clear Name",
MessageBoxButton.YesNo,
MessageBoxImage.Question) == MessageBoxResult.Yes)
{
p.Name = "";
}
}
}
I suppose you could leave all of the preparation code in the command and then call a Clear method on the Person. However, I'm still not convinced that is the best way. What if clear changes? You end up with Clear2 and Clear3 and so on. Not to mention a method for every possible use case or maybe even more.
Some More Thoughts
So let's say I have a View Model with a reference to a Model that allows pass-through Data Binding or it wraps the Model all together. What I want to get away from is creating a Command property on the View Model for every single use case. Also, what is so clean about that design? You're still mutating the Model object in the Execute method. I don't think I'm bending the Command Pattern all that much. My Window is the Client. The Model is the Receiver. And the Button is the Invoker. The only difference is you're injecting the dependency with the invoker.
To rephrase my question slightly, does anyone see any red flags for doing this?
I found this while researching the command pattern.
http://msdn.microsoft.com/en-us/library/cc984279.aspx
I really have no idea what you're talking about... you seem to have a very... er, unique way of working with Commands.
This requires the model to know how to perform the action on itself.
A model class should never have Commands in it... instead, put them in whichever view model that displays that model class.
... it's difficult to swap out behaviors
Again... what? Don't 'swap out behaviours'. A Command shouldn't change its functionality. Just create one for each function.
It's also difficult to find a place to put that "special case" code
What is "special case" code?
What if I want to show another view?
Each view should have its own view model. Each view model should have its own set of ICommand objects. It's really not a problem if you have to duplicate a little Lambda expression in a RelayCommand.
imagine that you had to log somewhere that the name was cleared? Undo Redo maybe?? Where does all this code go??!!
View model, view model, view model.
I suppose you could leave all of the preparation code in the command and then call a Clear method on the Person
What do you think the difference would be between calling p.Name = "" and calling p.ClearName() which did the same thing? No difference, or at most, it would take fractionally longer calling the method than setting the property directly.
What if clear changes? You end up with Clear2 and Clear3 and so on
Once again... what??? How would Name = "" change?
While I hope I answered some of your questions, I think that I must have misunderstood you in some way because I don't fully understand your question. Please feel free to ask further questions, but please add them as an edit to your question and I will reply in this answer, so that the comments don't get ridiculously long.
UPDATE >>>
In response to the first two comments:
Yes... in almost all cases, I would have one view for one view model. And no, I have absolutely no problem with changing the value of anything from a Command. I can't think of any reason why you would think that that is not OK. Imagine this scenario:
You have a list of objects and an edit panel in the UI that the user can use to edit the objects. You also have a Button with a Command that is named Duplicate. Now, by definition, that Command is going to 'mutate' as you call it, a data object, or model class.
It would create a new object and set its properties dependant on the values of the currently selected object. Are you suggesting that this Command is somehow wrong for doing this? In my opinion, that vast majority of Command (or method) functionality will 'mutate' some property or properties of the data objects in the view... how else do we provide this useful functionality?
And to continue with the 'where should this be?' question... where else can it be? In the view model, we have access to the currently selected item and the whole collection of items. From the view model, we can have access to any number of services that provide all kinds of functionality for us. You'd find it hard to connect with some of these things from your separate Command classes.
Related
OK, once again, my Google-Fu isn't up to par and I would really appreciate a little guidance here.
I have a WPF app with multiple pages, one of which contains a TabControl, of which one of the tabs contains a grid, in which one of the columns contains a StackPanel with just two items on it: a Label and a TreeView. I have no need to update the TreeView once the content is obtained. The app uses MVVMLight (great toolkit!) to expose the data and said data is exposed in an mvvm (observable) property as it should be. I have checked and the data itself is available in correct form once I get to the point of setting the ItemsSource property so I know it's not the lack of data or the structure of the data itself. I have looked at all the entries on the web (at least the first 4 pages worth) matching the search terms "wpf treeview dictionary" and all articles come close, but don't get me to where I need to be. I'm missing something and what's worse, IntelliSense is even "helping" by providing the correct values for the xaml settings. So I know I'm close, but after two days of frustration, I'm throwing in the towel and asking for an assist.
So...to the meat of the problem: The data that the TreeView needs to display is in the form of SortedDictionary<string, List<ServerEntityNameMsSqlSvr>>. A ServerEntityNameMsSqlSvr class contains multiple properties, one of which is FullName. What I want the TreeView to display is the dictionary Key as the parent node and the FullName from each of the items in the List<ServerEntityNameMsSqlSvr>. You'd think that'd be simple, no? Not for me, the closest I can get is to display the Key of the dictionary, but either nothing for the children (best case) or throw an exception that stops the app with a null exception (worst case).
Here is the xaml I'm using (worst case):
<TreeView Grid.Column="0" ItemsSource="{Binding TableHierarchy}">
<TreeView.ItemTemplate>
<HierarchicalDataTemplate ItemsSource="{Binding Path=Value}">
<TextBlock Text="{Binding Path=Key}"/>
<HierarchicalDataTemplate.ItemTemplate>
<DataTemplate DataType="awe:ServerEntityNameMsSqlSvr">
<TextBlock Text="{Binding FullName}"/>
</DataTemplate>
</HierarchicalDataTemplate.ItemTemplate>
</HierarchicalDataTemplate>
</TreeView.ItemTemplate>
"TableHierarchy" is the MVVM property that exposes the data, it is declared as SortedDictionary<string, List<ServerEntityNameMsSqlSvr>>. The DataType "awe:ServerEntityNameMsSqlSvr" is a simple class with a few methods and properties, nothing special. One layer of inheritance, no interfaces. Of the properties that are available, I want to expose just the FullName, which is declared as public string FullName => _FullName(); Yep, it calls an overloaded method to build the full name but the result is a simple string (and the method call happens when the data is built, not a display time, iow, the values are already there, at least debugging to the setter shows that the content is correct.
Some of the solutions that I have researched suggest that the data type be changed to something other than a dictionary. In this case, that's not possible and given that the lists are, on occasion, quite large, I don't want to rebuild it into something else. This needs to work with the sorted dictionary as declared.
The xaml shown above is indeed correct, however, the gadget that supports the data (the methods in the ServerEntityNameMsSqlServer class) all need to not throw exceptions under any circumstances. In this case, one of the methods not directly involved with the author's code but used somewhere else in the framework (an overloaded call to "Equals" that was constructed to check individual property equality to determine the result) was throwing a null exception because a property wasn't filled in for the particular use case.
Difficult to find, but that was the cause.
I have an issue trying to understand how to implement the MVVM pattern in my application. It's a small application and I will explain what it does.
My application creates a backup of files. The UI lets the user choose which folder they want to back up and where it should be backed up too. After making their selection they click the "start" button.
This then passes the folder source and folder destination to a class library (called backup.cs) which creates the back ups of all the files inside each folder. During this, a log (Log.cs) is created logging each stage and the state of each file it attempted to back up (complete, failed, other, etc). Now, the log is in memory only.
When the back up is complete I want a window to open (a view) which will display all the logs. It's at this point I can't understand how to use the MVVM pattern.
As it stands today, I pass my log (which holds the data in a hierarchical way) to my MainWindow's constructor and bind to the datacontext, using a treeview in my xaml I get the desired results. However, I now want to use MVVM.
My question is very similar to my previous question, as you can see the answer is to pass the log as a paramter to the ViewModel constructor. The issue is, I don't know how to do that and also display a window!
The only way (in my head) I can achieve this is by passing the Log as a parameter to a constructor of my View but this defeats the point of the MVVM. I could pass the parameter to my ViewModel's constructor (which would fit the MVVM pattern) but would that then mean I have to also create an instance of my View from my ViewModel constructor as well? Otherwise all I would do is create my ViewModel but have no way to display the results since the View isn't displayed.
I hope I have explained where I'm struggling clearly, can any one suggest a way forward please?
Most likely you 'll want the viewmodel to accept (and expose through a property) a collection such as a List<Log> -- typically this would be an ObservableCollection<Log>, but if the operation has already completed there is no real point in going that way. This is what you are describing as a possible solution.
To wire the viewmodel to the view, in essence you need to do this:
var viewModel = new LogsViewModel(...);
var view = new LogsView(); // no constructor parameters
view.DataContext = viewModel;
And finally you add view at some place of the application window's logical tree so that it gets displayed. MVVM frameworks automate this procedure, but you can also do it manually as simply as this.
Your view would then bind to the logs collection to display each log, perhaps using a DataTemplate:
<ItemsControl ItemsSource="{Binding Logs}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<!-- XAML to display each Log does here -->
<TextBlock Text="{Binding FileName}" />
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
As an example, if you wanted that LogView being shown based on a button click in you main View.
public override void ShowCommandExecute()
{
var popup = new LogsView
{
WindowStartupLocation = WindowStartupLocation.CenterScreen,
DataContext = new LogsViewViewModel();
};
popup.ShowDialog();
}
I want to know why we should use MVVM to implement Silverlight app. What're it's advantages?
We don't do Unit Test for ViewModel, so I want other reasons.
Below are my questions about some advantages people usually say:
1.Loosely Coupled : When we use MVVM , a view rely on ViewModel but not a view, why it's loosely coupled?
2.If I provide public methods in a code-behind, they can also provide reusability.
Well, the unit-testability of the view-model is a significant advantage, so you'll miss out on that benefit. Regarding the other two:
Loosely coupled
Yes, the view does rely on the view-model. They have to be connected in some way to accomplish the function of the application. As a result, they cannot be uncoupled. The only choices are tightly-coupled or loosely-coupled or somewhere in between. With MVVM your view-model interacts with your view in a very limited way: basically just objects, properties and commands. Compare this to doing everything in the code-behind where the view and its control are essentially inseparable.
Re-use
If any code in your code-behind is re-usable enough to merit being public, it can be taken out of the code-behind and put into a general-purpose class. The problem is that what's left after that is not reusable.
If you don't want to go into the MVVM deep dive, then you can get some of the benefits of MVVM by focusing on databinding. After you learn the benefits of databinding, you can reconsider the other benefits of MVVM.
We don't do Unit Test for ViewModel,
With MVVM, it isn't just about unit testing ViewModel. Ideally, your VM should be very thin and only have properties needed by view. So, it isn't really necessary to test the VM.
But, without a VM, how do you do your your feature/functional testing across layers? In Silverlight, to facilitate testing you should use commands, instead of writing code in code-behind files. This allows you to simulate button click and other GUI events while unit testing. Using MVVM pattern along with commands, you can test all of C# code (not xaml), right up to UI (Converter, VMs, etc).
If I provide public methods in a
code-behind, they can also provide
reusability.
Not going into details of how that is a bad design, I want to ask you, How does that provide reusablity? If you create a user control, then the code-behind class is a control? You want to create instances of your control and use them? This is like saying that why do we need member methods, we can just create public static methods and access them. I have a strong opinion that if we don't want to use the automatic binding provided by WPF/Silverlight, then it is better NOT to use these technologies. And to exploit the full capabilities of binding, MVVM is essential.
why it's loosely coupled?
VM is very much part of your view. It is not decoupled from the view. As I have said, your VM should be as thin as possible with only public properties needed by your view. Your business logic will be decoupled from your view (and VM).
I think this is one of the best resources available, in case you want to use and contrast the usage of MVVM vs. ANY other pattern or no pattern.
http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/
I can answer how I use MVVM pattern.
MVVM is better in the following scenarios:
1 If several controls are bound with a single property.
MVVM:
<TextBlock x:Name="text1" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>
<TextBlock x:Name="text2" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/>
I can quickly add a similar control or remove an existing control.
Compare with code-behind:
public string IsSomePropertyTrue
{
set
{
//...
text1.Visibility = value;
text2.Visibility = value;
}
}
2 Instead of a multi-converter
public Brush StateColor
{
get
{
if (this.State == State.Edited && this.IsPriority)
return new SolidColorBrush(Color.FromArgb(255, 0, 255, 0));
//...
}
}
<sdk:DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<TextBlock Background="{Binding StateColor}" Text="{Binding State}"/>
</DataTemplate>
</sdk:DataGridTemplateColumn.CellTemplate>
3 As an item model in controls like ListBox or DataGrid. For example, if I want to create a list of items with a remove button near each item, I will create a ItemView control and a ItemViewModel class.
<ItemsControl ItemsSource="{Binding SomeItems}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<view:ItemView DataContext="{Binding}"/>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
4 Copying a data from one view to another:
public JournalEntryViewModel(SalesOrderViewModel vm) {}
5 ViewModel can inherit CLR-classes and implement interfaces (INotifyPropertyChanged or INotifyDataErrorInfo).
Also I use MVVM for replacing events with commands or properties. And use of ViewModels forces to call properties by intelligible names.
I was an early adopter for WPF and I can tell you what made me choose MVVM (and this more or less applies to Silverlight as well). For the project I was working on, I had to create a screen that allowed users to subscribe to notifications within the system. This was a 3 step process:
The user had to search for the item they wanted to be notified about
They had to select the item and fill out additional options regarding the subscription
The system had to provide a summary and allow the user to confirm or edit the subscription.
After implementing the functionality the first time (without MVVM), I was told that we need to exclude from the search items that were already subscribed to by the user.
After making that fix, I was informed that we needed to give the user a live preview of the subscription based on options.
By then I started noticing that some of these changes could be extracted and made easier if I didn't have to deal with manipulating the UI as I changed the logic. I had never intentionally followed MVVM but I realized that the abstraction that I made closely matched the MVVM pattern.
So this is why I recommend the pattern. It simplifies the task of changing the logic that drives the UI by separating it from the UI itself. I also would recommend that you hold off implementing it until you need it. There is a cost to using MVVM but it is amortized over the cost of changing the UI logic.
Without MVVM, your Silverlight app code very soon will turn into unmanageable mess
What is also interesting in MVVM is dynamic automatic binding.
Imagine, that your view model has properties like this: bool IsFirstNameVisible, bool IsFirstNameEnabled, string FirstName, double FirstNameWidth etc.
In your XAML file, you define TextBox with x:Name = "FirstName" and call your dynamic MVVM-binder. It inspects your view model class via reflection, looks what properties you have defined and binds them dynamically to similar properties of control with the same name, applying value converters if needed.
In this case, your get very clean XAML, without kilometer-long data-binding expressions and converters.
That is what my MVVM library does.
Separation of Conerns people. Separation of Concerns.
Forget unit testing (I love it; but that's not the thing here). Forget reusability (do you really re-use view models? No, let's be real here).
It's about Separation of Concerns and putting code and logic where it belongs. The whole idea is maintainability; being able to make changes to the code as it evolves over time without breaking other stuff and without turning the whole thing into a big pile of spaghetti.
MVVM, done properly, allows your code to be separated into logical portions that make sense and allow for reasy refactoring and change as the app's requirements change. It's easier to find where something is when you need to make a change. Trying writing any halfway complex application and then leaving it alone for a month, then coming back to it and trying to make significant changes. A properly structured application with judicious use of MVVM is way easier to grok after a layoff, and it's way easier to make changes.
I have a View that displays a DataGrid which is bound to an ObservableCollection in the ViewModel. For the sake of discussion, let's say we have a Team View containing a Team DataGrid, in which each row represents a Player.
My question is about what data type I should use to represent the players in my Team collection. Is it a good idea for the items in the collection to be ViewModels themselves? In this case, my Team View would be associated with a single Team ViewModel as well as any number of Player ViewModels (in the Team collection).
Does having multiple ViewModels associated with a single View violate any design guidelines for MVVM , and is there a preferred way of implementing this scenario?
Thanks!
No that is fine; each object should be a ViewModel in its own right. It makes for cleaner code, nicer interactions, and remember, if it works well then it's correct (even if it violates guidelines).
I would do it exactly the way you are prescribing. I'd bind my grid to a Team, which would have an ObservableCollection<Player>, where Player is another ViewModel-type class. Each row item would get the Player as its DataContext and so you're still binding to ViewModel properties as you'd expect: and Player can still have public properties for ICommands (likely RelayCommands) for manipulation!
Hope that helps!
Far from violating guidelines, I think this is recommendated design. At least in my projects you will see this pattern repeatedly.
This pattern comes in particularly useful in conjunction with DataTemplates. For example you could define a DataTemplate in your Application.Resources for your PlayerViewModel like so:
<DataTemplate DataType="viewModels:PlayerViewModel">
<StackPanel Orientation="Vertical">
<Image Source="/Images/Player.png"/>
<TextBlock Text="{Binding Name}"/>
</StackPanel>
</DataTemplate>
And then if you wanted to display a list of players you simply bind a ListBox etc to your TeamViewModel.Players ObservableCollection and you automatically get the above DataTemplate displayed for each player:
<ListBox ItemsSource="{Binding Players}"/>
I agree with both of the other answers (the ones by Kieren and Groky) but feel they fail to mention a very important consideration in this decision.
You should only create a view model if there is something view-specific about what you are doing. If all you are doing is binding to data and invoking commands which naturally belong on your model, there is no reason to create a view model.
For example, suppose:
Your Player object has a Name property, a Rank property, a Promote() method, and a Delete() method.
Your view is a simple one that allows you to edit the Name and Rank of any player, and also has buttons to promote and delete players.
In this case adding a view model between your view and your model is pointless. Such a view can bind directly to the model:
Bind TextBox.Text to the Name property
Bind Slider.Value to the Rank property
Bind the Promote button to the Promote() method
Bind the Delete button to the Delete() method
Note that instead of binding the Delete button to the Delete() method you may want to set its Command to ApplicationCommands.Delete and use a CommandBinding to invoke the Delete() method.
My point here is that in most cases if your models are well-designed there will be no need to insert a view model object. A view model is only really necessary when view-specific state needs to be tracked (such as "current Player"), conversions are too complex to be handled by simple binding, or you need commands that affect several different model objects and/or view model properties at the same time.
In my experience, if the model is correctly designed only about 50% or so of all views actually need a view model, and in the case of items in a list this is more like 20%.
An example of a time when you might use a view model for an item in a list is when you need to keep a separate "selected" flag that is part of your view but not of your model, and the basic functionality in ListBox is not enough.
By CLEAN COD SOLID principles, it is nice to associate one view model to one view.
Separation of concerns should be separated for each view and it's much easier to maintain the codebase in the future.
You can do it but it's not recommended.
I'm starting to use Binding in my WPF project and I'm actually confused about few things on the presentation side (XAML).
So I want to populate a TreeView with a List of Categories. I know how to write the right HierarchicalDataTemplate for my List of Category instances.
<HierarchicalDataTemplate ItemsSource="{Binding Path=ChildrenCategories}" DataType="{x:Type src:Category}">
<TextBlock Text="{Binding Path=Name}"></TextBlock>
</HierarchicalDataTemplate>
But what now I don't know is from where to get the list. I have here 2 solutions :
I got a Library Singleton class
which return me the right
arborescence, then I need to use an
ObjectDataProvider in my xaml which
would call the
Library.Instance.Categories method. (Which means that the controller has to be completely separated from the UI).
I got a Property ListCategories
in my page interactionLogic
(OpenUnit.xaml.cs), and bind the
tree with it.
I'm not sure about the purpose of the xaml.cs files, what are they made for? Is it normally used to store the properties (and act as a controller) or simply to have a back-end for the UI (for example get values from the UI?)?
In case the xaml.cs file is used as a controller, how do I bind my data to it, I've tried many solutions without success,my only success was with the use of static binding.
I would appreciate any comment or recommandation about UI and Logic Binding in WPF, hopefully I will get less confused.
Thanks in advance,
Boris
After reading this great article, I got a little bit less confused :
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
The article is about the Model View ViewController pattern, and how WPF integrates it. So it seems that xaml.cs files should be used as the ViewController here, and should hold the properties.
It actually make sense since it's not a good practice to mix the View and the Data, we want the designers should have a completely independant work to do.
Also for the solution 2) it is possible if you set the data context to the current file.