I'm creating an application in WPF using MVVM. I have a tab called tab1, which is a UserControl and has an associated DataModel (but no View, and thus, no ViewModel). Within tab1's content, there is a ListView, inside which is a button. The problem is that I would like the button to work. It worked when tab1 had an associated Tab1ViewModel, but I am told it must have a DataModel and not a ViewModel. I don't believe DataModels can support commands, so does anyone know of a workaround for this? Or does there really just need to be a ViewModel for any nested control with buttons?
Not having a view-model associated with the view is "kind of" against the guidelines of MVVM.
I can think about two solutions :
If you are "allowed", you can inherit the DataModel and add some
"ViewModel functionality" (Like the button's command)
If you are "allowed", have a view-model that contains the data-model (in this method you lose the ability to listen property changes if bind your view to the nested data-model fields)
Add the event handler in view's code-behind (which is against the MVVM's guidelines)
These two solutions aren't that great so I suggest that you try to solve the issue that leads to the facts that you can't use a view-model with your view and solve that.
I have multiple of views (user controls), each with its own ViewModel. To navigate between them I am using buttons. Buttons display image and text from corresponding view model and also need column and row (because there are like 10 views: 10 columns with different number of rows each).
Right now buttons are created dynamically (I made a Navigator control for this) and for view models I have base class to hold text, image, column and row. Number of views available will be different (depends on user level and certain settings), that's why it's I need control here.
Question: how shall my control get data from view models?
Right now I have interface INavigator, defined in (lol) control itself. And view models implement it. I could go opposite, let my control to know about view models. Both looks wrong.
There is a single Navigator control what has, lets say, Items bound to a list of view models. It can cast each view model to INavigator or ViewModelBase (common for all pages) to obtain specific view model image, text, column and row. So either view model knows about control (to implement INavigator) or control knows about ViewModelBase.. And this is a problem, both solution bind tight control and view models, which is bad in mvvm.
Schematically
The way you've drawn your diagram answers your own question as to how you should structure the code for this.
What you need is one VM (let's call it MainVM) which contains an ObservableCollection<VMBase> of the other VMs (using your base type so that they can all happily live in the same collection).
Your View needs an ItemsControl (bound to your ObservableCollection<VMBase>) where you specify a DataTemplate for the Button using the properties exposed by the VMBase type only. Set the Command property in the Button to call SwitchCommand, CommandParameter is set to the item itself (i.e. {Binding .}).
Your View also needs a ContentControl bound to a SelectedVM property on MainVM which you can populate.
Implement SwitchCommand to set the SelectedVM property based on the value from the CommandParameter.
public void ExecuteSwitchCommand(object parameter)
{
var vmBase = parameter as VMBase;
if (vmBase != null)
SelectedVM = vmBase;
}
All properties mentioned here should be INotifyPropertyChanged enabled so that the View registers when they change and updates the UI.
To get the different UIs for the ContentControl, add type-specific DataTemplates for each of your specific VM types to the Resources file of your View (or if you're smart and are building a custom plug-in framework, merge the Resource Dictionaries).
A lot of people forget with MVVM that the whole point is that there is a purposeful separation of View from ViewModel, thus meaning you can potentially have many Views for a single ViewModel, which is what this demonstrates.
I find it's easiest to think of MVVM as a top-down approach... View knows about it's ViewModel, ViewModel knows about its Model, but Model does not know about its ViewModel and ViewModel does not know about its View.
I also find a View-first approach to development the easiest to work with, as UI development in XAML is static (has to be).
I think a lot of people get to wrapped up in 'making every component (M, V, VM) standalone and replaceable', myself included, but I've slowly come to the conclusion that is just counter-productive.
Technically, sure you could get very complicated and using IoC containers, create some ViewLocator object which binds a View-type to a ViewModel-type, but... what exactly does that gain you besides more confusion? It makes it honestly harder (because I've done this at one point) to develop because now you've lost design-time support first and foremost, among other things; and you're still either binding to a specific view model interface in your view or creating the binding at run-time. Why complicate it?
This article is a good read, and the first Note: explicitly talks about View vs. ViewModel. Hopefully, it will help you draw your own conclusions.
To directly answer your question, I think having your ViewModels implement an INavigator interface of some sort is probably ideal. Remember your VM is 'glue' between your view and model/business logic, its job is to transform business data into data that is consumable by your views, so it exists somewhere between both your UI and business layers.
This is why there are things like Messengers and View Services, which is where your navigator service on the ViewModels can fit in nicely.
I think the design has led to a no way out situation.
I believe that creating a custom button control where the dependency properties tie the image, the row and column actually provide a way for the page, which it resides on ,to get that information to them; whether they are dynamically created or not.
Continuing on with that thought. There is no MVVM logic applied to a custom control, the control contains what it needs to do its job and that is through the dependency properties as mentioned. Any functionality of the button should be done by commanding; all this makes the button data driven and robust enough to use in a MVVM methodology or not.
Question: how shall my control get data from view models?
There should only one viewmodel which is the page the control resides on. The control is simply bound to information which ultimately resides on that VM. How it gets there, that is up to the programmer. If the button is going to contain state data, that is bound from its dependency property in a two way fashion back to the item it is bound to.
By keeping VMs out of the buttons and only having one VM that is the best way to segregate and maintain the data. Unless I am really missing something here....
Same as others here I find it a bit hard to actually understand what you are asking, so this is quite general. The answer to the question header is simply: the Control gets the data from the ViewModel through bindings, always. You set the DataContext of your Control to the corresponding ViewModel, and from there you keep the ViewModel and the Control synchronized:
If you add an ItemsControl containing buttons to the View, you add an ObservableCollection<ButtonViewModel> to the ViewModel and bind the ItemsSource of the ItemsControl to this.
If you allow the user to dynamically add content to the View, the actual code that does it resides in the ViewModel, e.g. when the user clicks on a button "Add Button", you use the Command property to call a ViewModel method that adds a ButtonViewModel to the collection and the View will automatically reflect your changes.
There do exist complicated cases that are impossible to code exclusively in the ViewModel, I have found Behaviors to be the missing link there, but I'll get into that when you show me the specific case.
If you'd like to get a working example, please provide as much code as you can, with your exact expectations of what it should do.
http://s7.directupload.net/images/140511/66z6w2tq.jpg
As you can see on the picture I am explaining everything with a Schema, I have a TabItem and on this TabItem I want to change the DataContext everytime with a Button. What I mean,is that I want to navigate through different UserControls but to stay on the same TabItem from a TabControl. I dont know how to Navigate through different ViewModels and everytime my values not to change from my Elements. I also could not find an Example of the same situation. Any Help with a Code Snippet or a full example will be appriciated.
Thanks in advance.
WPF/MVVM
I think this is a good case for using pub sub with EventAggregator or MvvmLight's Messenger.
You can then loosly coupled notify the MainViewModel to exchange controls or views within a tab.
Basically you can notify another ViewModel with another scope to do certain changes and then subscribe to it.
A possible structure could be:
- A MainViewModel with a collection of TabItemViewModels
- A single TabItemViewModel could contain also Controls and nested ViewModels
If you want to change a tab send a ChangeTabMessage to the MainViewModel
If you want to navigate within a tab use also Messaging or navigate as you do today.
Check out the EventAggregator here: http://msdn.microsoft.com/en-us/library/ff921122.aspx
or check out MVVMligh Toolkit Messenger ...
HTH
I am in the process of re-writing one of our large Silverlight apps to use PRISM and the MVVM design pattern.
A very common scenario is a DataGrid in the View. Double clicking a row allows the user to edit the entity represented by the row, using a ChildWindow.
I am tempted just to capture the DoubleClick event in the code behind, create a new ChildWindow of the proper type, and set the DataContext to be DataGrid.SelectedItem.
I know that this is not the proper way to handle this scenario with PRISM and MVVM, however.
I would love advice on what is! (re: my title...it seems like InteractionRequest might be the best way to do this?)
Thanks...
EDIT: We did end up deciding to go with InteractionRequest for our solution. We almost always use "Notification" as the type and pass a new ViewModel (each ChildWindow has its own) as the Content.
In our case the ChildWindow view was complex enough to warrant its own viewmodel. This view isn't too closely coupled with the data grid view.
So, we have an EventTrigger attached to the data grid (we actually use Telerik's data grid) in XAML. The event trigger executes a command in the view model using InvokeCommandAction.
The command publishes an aggregated event that has the selected item as the payload. The event is picked up by the central application controller that is responsible for creating the ChildWindow view and a corresponding view model (using the event payload as the context).
I think that interaction request could potentially be used in your case, but based on my understanding the idea behind an interaction request is a very simple Ok or Yes/No interaction. You might be pushing the boundaries with a bunch of text boxes, validation, etc.
in my view, i have two chart controls of type MyChart:
MyChart1
MyChart2
The chart user control has a button called Refresh. Clicking on the button refreshes their item source and they display new data.
In the ViewModel of the view, I have two properties of type MyChart, one for each MyChart.
When I click on the Refresh button, how do I raise RaisePropertyChanged event of the view model of the view?
This is not a correct implementation of MVVM, as you have application logic coded into the View layer.
The standard approach would be to have a Command property on your ViewModel, then bind Button.Command to the ViewModel.Command. This will allow you to handle the refreshing in the ViewModel and give you a place to write any additional code you need to write.
To answer your question, if you are using MVVM, the properties displayed in the View actually exist in the ViewModel, so you should be able to handle PropertyChanged easily enough in the ViewModel using this.PropertyChanged += new PropertyChangedEventHandler(ViewModel_PropertyChanged);