Category: MVVM

MVVM Basic Binding – reflecting multiple targets

I have a ViewModel implementing INotifyPropertyChanged interface and have at least two properties Value and IsChanged. When I bind two Textboxes to the Value on source and one check box to IsChanged property of the source I noticed that user changes to Value does not reflect the other target controls!
This behavior is due to the fact that my ViewModel was not provided as a field in my container ViewModel and rather it was created when needed.
public PandViewModel PandViewModel
{
   get
   {
       return listIndex < 0
       ? null
        : new PandViewModel(panden[listIndex]);
   }
}

Moving the PandViewModel to a local field in this container class, or even putting it into an ObservableCollection will sort out the problem: 

public PandViewModel PandViewModel
{
    get
    {
        return listIndex < 0
        ? null
        : pandenVM[listIndex];
    }
}

See also a nice article over Binding on MSDN.

MVVM Basic Principals

The very basic principals so far I understand from M-V-VM practice is the following which is understood from this article : http://msdn.microsoft.com/en-us/magazine/dd419663.aspx#id0090025

View is a Control or Window

public partial class CustomerView : System.Windows.Controls.UserControl
{
public CustomerView()
{
InitializeComponent();
}
}

And this is as far as the view might be written in code. In the most cases we don’t want to write more code in the View. The reason is that the View is supposed to be made loosely coupled from the data and the logic, probably done by creative designers.

The View gets DataContext

Some magic forces will get the data that is accessible through the ViewModel and set it to the DataContext property of the control:

protected override void OnStartup(StartupEventArgs e)
{
base.OnStartup(e);

var viewModel = new MainWindowViewModel(path);
MainWindow window = new MainWindow();
window.DataContext = viewModel;

window.Show();
}

In this example the magic happens in the Startup method of the application. Using MEF this magic is taken out to some sophisticated standard way.
Now the View and its elements are ready to consume the data.

View binds to ViewModel

Both data and actions are binded to public accessors of ViewModel:

 <TextBox
    x:Name="firstNameTxt"
    Grid.Row="2" Grid.Column="2"
    Text="{Binding Path=FirstName, ValidatesOnDataErrors=True, UpdateSourceTrigger=PropertyChanged}"
    Validation.ErrorTemplate="{x:Null}"
    />

<Button 
  Command="{Binding Path=SaveCommand}"
  Content="_Save"
  />

ViewModel is unaware of View

Unlike the Presenter in MVP, a ViewModel does not need a reference to a view. This makes it possible to attach any View at any time to consume the public data provided by ViewModel.

ViewModel exposes public properties to share data with any possible View:

public class CustomerViewModel : WorkspaceViewModel, IDataErrorInfo
{
    public string FirstName
    {
        get { return _customer.FirstName; }
        set
        {
            if (value == _customer.FirstName)
                return;

            _customer.FirstName = value;

            base.OnPropertyChanged("FirstName");
        }
    }

ViewModel exposes public commands to share actions with any possible View:

/// <summary>
/// Returns a command that saves the customer.
/// </summary>
public ICommand SaveCommand
{
    get
    {
        if (_saveCommand == null)
        {
            _saveCommand = new RelayCommand(
                param => this.Save(),
                param => this.CanSave
                );
        }
        return _saveCommand;
    }
}

Some of these properties may be data coming from a model and some might be simply a state of the ViewModel to help out the View.

Data Manipulation

The ViewModel, never the View, performs all modifications made to the model data.
As I already mentioned the ViewModel is unaware of View but it is certainly aware of Model and can manipulate it when needed. When user interacts with the View, the binding manager will take care of both ways of data modifications in each binding.

The way a ViewModel is attached to a model, is an architectural decision and makes your application easier or hard to understand and maintain. But this is another important subject. For now, like MEF does the magic for coupling View and ViewModel, there needs to be some Factory or Controller mechanism to pull the data and assign it to the ViewModel.