MVVM Implementation for WinForm application

Question

I am trying to implement MVVM (Model View ViewModel) pattern for my WinForms application. I am using C# 2005.

My application has a MainForm (View) with 2 multi line textboxes and 3 buttons. The purpose of the 1st textbox is to show a running commentary of what the application is doing, when the button is clicked. I keep on appending lines to the TextBox to update the user what is happening. The purpose of the 2nd textbox is to update the user about any error condition, conflicts, duplicate values; in short, anything which is required by the user to review. It classifies each message as either an INFO or a WARNING or an ERROR. Each of the 3 buttons perform an action, and keeps updating the 2 textboxes.

I have created a MainFormViewModel class.

1st question: When the user clicks on the button in MainForm, I have to clear the contents of the 2 textboxes, and disable the button so that it cant be clicked again until 1st operation is completed. Should I do this textbox and button updation directly in the MainForm or I should use MainFormViewModel in some way?

2nd question: The button click calls a method on the MainFormViewModel class. Before calling the method and after calling the method, I want to show a message in the 1st textbox something like "Operation A started / ended". I do this by calling a Common class which has a Log method to log messages to a TextBox or a file or both. Again whether it is ok to do this directly from the MainForm? I call this logging method at the start and end of the event handler.

3rd question: How do I propagate error messages from ViewModel back to View? I have created a custom Exception class "TbtException". So do I have to write 2 catch blocks in each and every button, one for TbtException and other for genetic Exception class?

Thanks.

Answer 1

You should perform operations in the view only with regard to the state of the ViewModel object. E.g. you shouldn't assume the view model is calculating when you click a button, but you should add a state to the view model that says it's doing something longer and then recognize that state in the view. You shouldn't disable or enable buttons in the view as you please, but only if there's a state that demands these buttons to be changed. This can go as far as to have a property that indicates which item in a list is currently selected, so the UI doesn't call the list control's SelectedItem member, but the viewmodel's. And when the user clicks remove, then the view model will remove the selected member from its list and the view is automatically updated through state changes in the form of events.

Here's what I would call a view model for your view. It exposes messages through an observable collection to which the view can bind (ie. register event handlers, since binding is not well supported in WinForms). The textbox at any time renders only the contents of the collection. It has actions for clearing those collections which your view can call. The view can also call actions of the underlying model, but it should be updated through the viewmodel only! The view should never register any event handlers for events exposed by the underlying model. If you ever want to do that you should hook up that event in the view model and expose it to the view there. Sometimes that may feel like "just another level of indirection" which is why it may be overkill for very simple applications such as yours.

public class MainFormViewModel : INotifyPropertyChanged {
  private object syncObject = new object();

  private MainFormModel model;
  public virtual MainFormModel Model {
    get { return model; }
    set {
      bool changed = (model != value);
      if (changed && model != null) DeregisterModelEvents();
      model = value;
      if (changed) {
        OnPropertyChanged("Model");
        if (model != null) RegisterModelEvents();
      }
    }
  }

  private bool isCalculating;
  public bool IsCalculating {
    get { return isCalculating; }
    protected set {
      bool changed = (isCalculating != value);
      isCalculating = value;
      if (changed) OnPropertyChanged("IsCalculating");
    }
  }

  public ObservableCollection<string> Messages { get; private set; }
  public ObservableCollection<Exception> Exceptions { get; private set; }

  protected MainFormViewModel() {
    this.Messages = new ObservableCollection<string>();
    this.Exceptions = new ObservableCollection<string>();
  }

  public MainFormViewModel(MainFormModel model)
    : this() {
    Model = model;
  }

  protected virtual void RegisterModelEvents() {
    Model.NewMessage += new EventHandler<SomeEventArg>(Model_NewMessage);
    Model.ExceptionThrown += new EventHandler<OtherEventArg>(Model_ExceptionThrown);
  }

  protected virtual void DeregisterModelEvents() {
    Model.NewMessage -= new EventHandler<SomeEventArg>(Model_NewMessage);
    Model.ExceptionThrown -= new EventHandler<OtherEventArg>(Model_ExceptionThrown);
  }

  protected virtual void Model_NewMessage(object sender, SomeEventArg e) {
    Messages.Add(e.Message);
  }

  protected virtual void Model_ExceptionThrown(object sender, OtherEventArg e) {
    Exceptions.Add(e.Exception);
  }

  public virtual void ClearMessages() {
    lock (syncObject) {
      IsCalculating = true;
      try {
        Messages.Clear();
      } finally { IsCalculating = false; }
    }
  }

  public virtual void ClearExceptions() {
    lock (syncObject) {
      IsCalculating = true;
      try {
        Exceptions.Clear();
      } finally { IsCalculating = false; }
    }
  }

  public event PropertyChangedEventHandler PropertyChanged;
  protected virtual void OnPropetyChanged(string property) {
    var handler = PropertyChanged;
    if (handler != null) handler(this, new PropertyChangedEventArgs(property));
  }
}

EDIT: Regarding exception handling

I would rather catch exceptions in the ViewModel than in the view. The view model is better suited to prepare them for display. I don't know how that works in WPF though. I've yet to program an application in WPF, we're doing a lot of WinForms still.

Opinions may vary, but I think generic try/catch clauses aren't really exception handling. I think you should rather test your UI very well and include exception handling only when necessary. Which is why you unit test your view model and user test the view. However if you really stick to the principle and avoid logic in the view, you can do a lot with unit tests.