In all tutorial about MVVM I read that View
should not know about Model
, hence ViewModel
layer is introduced.
If so in situation like: we have Shelf
which contains Pack
:
namespace Storage.Model
{
class Pack
{
public string Name { get; set; }
}
}
<UserControl x:Class="Storage.View.Shelf" ... >
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="20" />
<RowDefinition Height="50" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<TextBlock Grid.Row="0" Text="{Binding Path=Name}"/>
<TextBlock Grid.Row="1" Text="{Binding Path=Capability}"/>
<ItemsControl Grid.Row="2" ItemsSource="{Binding Path=Packs}">
<ItemsControl.ItemTemplate>
<DataTemplate>
<Border>
<TextBlock Text="{Binding Name}" />
</Border>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
</Grid>
</UserControl>
// DataContext for Shelf
namespace Storage.ViewModel
{
public class ShelfViewModel
{
public string Name { get; set; }
public string Capability { get; set; }
// It's okay that ViewModel contains collection of another ViewModel?
public ObservableCollection<PackViewModel> Packs { get; set; }
}
}
// DataContext for Pack
namespace Storage.ViewModel
{
class PackViewModel
{
private Pack pack;
public string Name
{
get{ return pack.Name; }
set{ ... }
}
public PackViewModel(int id)
{
// How to populate reference to Pack instance?
pack = (new PackRepository()).getById(id)
}
}
}
Like I mention in code comment above, it okey that one ViewModel create instances of another ViewModel? I can image case where we have Storage
with collection of Shelf
, hence we end up with cascading reference to ModelView: StoreViewModel
contains ObservableCollection<ShelfViewModel>
which cotains collection of ObservableCollection<PackViewModel>
.
Another problem with arise with that solution is that how to populate newly introduced PackViewModel
with reference to Pack
class? We must somehow pass unique identifier to PackViewModel
instance.
I don't want hide that this question is related to my other question Shoud view layer know about model classes (entities)?
Yes. In this case
PackViewModel
is just a wrapper aroundPack
. You typically use such a wrapper when you don't want to expose or bind to the model type directly or when the model type doesn't implement theINotifyPropertyChanged
interface for example.This is perfectly fine. You will indeed end up with more classes, but each class has its own responsibility. You could for example extend the wrapper class with properties that are specific to the UI, i.e. properties that are obly there for the view to bind to.
You could just inject the wrapper class with the wrapped object when you create it:
Given a collection of
Pack
objects that you may have received from some kind of repository or service, you could then easily create wrapper objects, e.g.: