I'm trying to understand the basic MVVM design approach when using ItemsControl by binding it via DataTemplates to ObservableCollections on the ViewModel.
I've seen examples that bind to ObservableCollections of strings, Views, and ViewModels.
Binding to strings seems to be only for demos, it is the binding to "ViewModels that contain collections of Views that contain collections of ViewModels" that the power of WPF seems to really come out.
For those of use proficient in the MVVM pattern, what is your standard approach to binding ItemsControl, ListView, ListBox to collections in a ViewModel? I'm looking for advice from experience like this:
always use ObservableCollection<...> and never List<...> because...
something better than ItemsControl to display a collection is...
in order to get filtering to work in your ViewModel instead of code-behind, use...
use collections of Views when ... and collections of ViewModels when...
90% of the time I create an ItemsControl and bind it to an ObservableCollection of Views which have their own ViewModels...
I would use an ObservableCollection of ViewModels for the following reasons:
ObservableCollection already has events available for signaling when it has been modified (e.g. when items are added/removed from the collection).
We're at the ViewModel 'layer' so it provides cleaner separation to have a ViewModel contain a collection of ViewModels rather than Views
If it is necessary to modify or get data from items within the collection you can more easily modify/access that data if the items are ViewModels (if they're views you'll frequently be casting the View's DataContext or accessing its UI elements).
I like using an ObservableCollection of ViewModels. The view that binds to the collection can define a DataTemplate that gives the ViewModel its look. This leads to less coupling among the components.
I have the same question, but replace the "view" with "model". :)
I have a MODEL with a collection of other models.
I want my viewmodel to have an observable collection of other viewmodels, but once I instantiate it like that - the connection between the model collection content is lost.
Do I now need to start wiring all the events from the viewmodels observable collection back to the models collection?
Related
I am fairly new to WPF and MVVM.
I see that a DataGrid can be bound to a CollectionViewSource or an ObservableCollection or a DataSet.
What is the significance of using one over the other?
CollectionViewSource is the XAML equivalent (can be instanciated in XAML) for CollectionView, which provides functionality for grouping, sorting, filtering, and navigating in any data collection. If you want to provide any of these features in the view (XAML) only and do not want to do this in the viewmodel, use a CollectionViewSource else use the ObservableCollection or CollectionView in your viewmodel. Use a DataSetwhen you have your data already in that form and do not want to go through the hassle of creating a viewmodel.
I mostly use the ObservableCollection in the viewmodel.
I would not recommend you using DataSet. You could sort, group and filter data using CollectionViewSource.
I have an ObservableCollection of Products in the Model, and I want the ViewModel to listen to any changes in the ObservableCollection of Products.
Im not sure about how to go and implement it. Ive read several tutorials, but most of them are not MVVM specific.
Should i implement the INotifyPropertyChanged in the ViewModel class, how do I specify that i want to listen to the OberserableCollection of Products?
Thanks :)
I know this has already been answered, but there is more to consider.
1) a ViewModel should implement INotifyPropertyChanged, that's one of the things that makes it a ViewModel. Even in the unlikely case that the only property it exposes is the ObservableCollection, it will need to raise property changed when the actual ObservableColelction property is changed (more on this in item 3)
2) do you really want the ViewModel to listen for these changes or the View? Those are two different things. The ViewModel should hold an ObservableCollection which is then bound to the View. What you want is for the View to react to those changes. In that case, Brandon is correct that ObservableCollection does this for you out of the box. So the View has an instance of the ViewModel set as a DataContext and some visual element in your View is bound to the ObservableCollection (like an ItemsSource on a ListBox).
3) the exception is the ObservableCollection property itself in the ViewModel. While ObservableCollection implements INotifyPropertyChanged, that is part of the collection object: when that object reference changes (like it is recreated) in the ViewModel, then the ViewModel still needs to report that the Property for the ObservableCollection has changed.
Just some thoughts.
ObservableCollection already implements INotifyPropertyChanged, so you don't need to.
I am building an object model with strongly typed collection classes (e.g. CustomerCollection). I want to support full two-way binding on both the collection itself and all of the data models in the collection.
For the models it seems like implementing INotifyPropertyChanged is the right way to wire up the models. But what inferface/base class should I use so that WPF knows when my collection's contents change?
ObservableCollection<T> - designed specifically for WPF binding.
I would recommend typing your properties that you expose as IList, or IEnumerable (generic or not, your choice), rather than ObservableCollection since it ties you into that implementation, and there are a number of situations that this becomes annoying.
The specific interface you need your collections to implement is INotifyCollectionChanged.
I'm developing a WPF application using the MVVM pattern and I need to display a list of items in a ListView (with filtering), with the fields of the selected item displayed in a Master/Detail view. I'm torn between the following two ways of doing this:
Exposing a CollectionView in my ViewModel, and binding to this.
Exposing a plain IList in my ViewModel, and using CollectionViewSource to create the CollectionView in XAML.
Is there an accepted way of doing this? Any thoughts on the best way?
I do the former (expose CollectionView from the VM) but what really matters is where your filtering logic is. That should definitely be in the VM so that it can be tested, even if the view has to wire up the CollectionViewSource to the VM. That said, I don't think there's anything particularly nasty or anti-MVVM about exposing a CollectionView from your VM.
I know I'm a bit late answering your question but I just saw it today.
I have created master/detail viewmodels that use the CollectionViewSource and blogged about it.
I wrote about a viewmodel for master/detail tables here that uses :
http://reyntjes.blogspot.com/2009/04/master-detail-viewmodel_24.html
You can also find a viewmodel for the observablecollection class on my blog pages.
Maybe you find it of use to you.
I have two ViewModels that present the same Model to different Views. One presents the model as an item in a ListBox, the other presents it as a tab in a TabControl. The TabControl is to display tabs for the items that are selected in the ListBox, so that the tabs come and go as the selection changes.
I can easily synchronise the two controls by adding an IsSelected property to the Model and binding the ViewModels to it (a bit like this), but this will clutter the Model with presentation details that don't really belong there.
It seems like I need something between the Model and ViewModels to hold this extra state. Are there any patterns or examples of a good way to do this?
Use a ViewModel.
You've got a View that contains the two controls. Have a view model that will contain a list of ViewModels for the ListBox control to bind to. Also within this view model bind the listbox selection to a second list of viewmodels that the TabControl then also binds to.
That way your listbox drives what the tab control shows without this information entering the model which should stay oblivious to the existence of the view.
TabControl is ItemsControl, so you shouldn't be shy to bind its ItemsSource to ListBox.SelectedITems.
Obviously ViewModel for List should have a property that would produce ViewModel for Tabs:
public TabViewModel ItemTabModel { get { ... } }
And because TabControl is a bit funny, you'd need to add ItemContainerStyle to populate Content for TabControlItem, because the normal ItemTemplate for TableControl only affects headers for tabs.