Question

I’m newer to C# and have just discovered how to use yield return to create a custom IEnumerable enumeration. I’m trying to use MVVM to create a wizard, but I was having trouble figuring out how to control the flow from one page to the next. In some cases I might want a certain step to appear, in others, it doesn’t apply.

Anyway, my issue is that I’m using an IEnumerable to return each subsequent page, which works really great, but I know I’m probably doing something improper/unintended with the language. The child class only has to override the abstract Steps IEnumerable accessor:

public class HPLDTWizardViewModel : WizardBase
{
  protected override IEnumerable<WizardStep> Steps
  {
    get 
    {
      WizardStep currentStep;

      // 1.a start with assay selection
      currentStep = new AssaySelectionViewModel();
      yield return currentStep;
      // 1.b return the selected assay.
      SigaDataSet.Assay assay = ((AssaySelectionViewModel)currentStep).SelectedAssay;
      sigaDataSet = (SigaDataSet)assay.Table.DataSet;

      // 2.a get the number of plates 
      currentStep = new NumPlatesViewModel(sigaDataSet);
      yield return currentStep;
      ...
    }
  }
}

The parent class contains the navigation logic using the Steps attributes’ enumerator:

public abstract class WizardBase : ViewModelBase
{
  private ICommand _moveNextCommand;
  private ICommand _cancelCommand;
  private IEnumerator<WizardStep> _currentStepEnumerator;

  #region Events

  /// <summary>
  /// Raised when the wizard window should be closed.
  /// </summary>
  public event EventHandler RequestClose;

  #endregion // Events

  #region Public Properties

  /// <summary>
  /// Gets the steps.
  /// </summary>
  /// <value>The steps.</value>
  protected abstract IEnumerable<WizardStep> Steps { get;}

  /// <summary>
  /// Gets the current step.
  /// </summary>
  /// <value>The current step.</value>
  public WizardStep CurrentStep 
  {
    get 
    {
      if (_currentStepEnumerator == null)
      {
        _currentStepEnumerator = Steps.GetEnumerator();
        _currentStepEnumerator.MoveNext();
      }

      return _currentStepEnumerator.Current; 
    }
  }

  #endregion //Public Properties

  #region Commands

  public ICommand MoveNextCommand
  {
    get
    {
      if (_moveNextCommand == null)
        _moveNextCommand = new RelayCommand(
            () => this.MoveToNextPage(),
            () => this.CanMoveToNextPage());

      return _moveNextCommand;
    }
  }

  public ICommand CancelCommand
  {
    get
    {
      if (_cancelCommand == null)
        _cancelCommand = new RelayCommand(() => OnRequestClose());

      return _cancelCommand;
    }
  }

  #endregion //Commands

  #region Private Helpers

  /// <summary>
  /// Determines whether this instance [can move to next page].
  /// </summary>
  /// <returns>
  ///   <c>true</c> if this instance [can move to next page]; otherwise, <c>false</c>.
  /// </returns>
  bool CanMoveToNextPage()
  {
    if (CurrentStep == null)
      return false;
    else
      return CurrentStep.IsValid();
  }

  /// <summary>
  /// Moves to next page.
  /// </summary>
  void MoveToNextPage ()
  {
    _currentStepEnumerator.MoveNext();

    if (_currentStepEnumerator.Current == null)
      OnRequestClose();
    else
      OnPropertyChanged("CurrentStep");
  }

  /// <summary>
  /// Called when [request close].
  /// </summary>
  void OnRequestClose ()
  {
    EventHandler handler = this.RequestClose;
    if (handler != null)
      handler(this, EventArgs.Empty);
  }

  #endregion //Private Helpers
}

And here is the WizardStep abstract class which each wizard page implements:

public abstract class WizardStep : ViewModelBase
{
  public abstract string DisplayName { get; }

  public abstract bool IsValid ();

  public abstract List<string> GetValidationErrors ();
}

As I said, this works wonderfully because I navigate the list with the Enumerator. Navigation logic is in an abstract parent class and all the child has to do is to override the Steps attribute. The WizardSteps themselves contain logic so that they know when they are valid and the user can continue. I’m using MVVM so the next button is bound to the CanMoveToNextPage() and MoveToNextPage() functions through a Command.

I guess my question is: how wrong is it to abuse the enumeration model in this case? Is there a better way? I really need to define the control flow somehow, and it just fit really well with the yield return ability so that I can have flow logic return to the Steps accessor to get the next page.

Answer 1

I think that as long as something fulfills the requirements, is easy to maintain and is easy to read, then it can’t be that bad.

Obviously as you’ve guessed this isn’t classical use of IEnumerable. But, yield returns are almost always used (in my experience, at least) for slightly off-beat situations like this. As long as you won’t need “< Back” support, I’d leave the solution as-is.

As for alternatives, I’ve used multiple approaches, none are really to my taste. Wizards with branching paths are always slighlty messy.

For heavyweight wizards, one option is a state machine. Write a one or two methods that knows how to traverse between states, and what transitions are valid. Build a UserControl for each state and expose them to a TabControl through a ListCollectionView.

A nice lightweight solution I used once is to pile all the pages in the wizard on top of each other in a grid and to toggle their visibility by binding to a State represented by an Enumeration. Using a ValueConverter you can even avoid magic numbers. Switching between pages then simply becomes a matter of incrementing or decrementing the Status property.