John Luif

On the CAB message board I see a lot of people talking about State and dependency injection.  I don’t see many people talking about the StateChanged attribute.  Using this attribute can yield an easily maintainable and extensible workitem.

In my case I had many views and presenters that all depended on the same state.  The state was initially null until the user selected an item.  To leverage the StateChanged attribute I created a new presenter base class which contained the below:

    protected abstract void UpdateDataSources(Customer customer);

    [StateChanged(“Customer”)]
    public void CustomerStateChanged(object sender, StateChangedEventArgs args)
    {
        UpdateDataSources(args.NewValue as Customer);
     }

All my presenters that need to now when the customer changed get notified via the UpdateDataSources method.  In the presenters that receive the call to “UpdateDataSources” just update the datasources for the view.  In the view you should be using a binding source so you just need to set the DataSource of the BindingSource.

In my scenario I did not need State injection but if you do the presenter base class may look something like:

   public abstract Customer UpdateDataSources { set; }

   [StateChanged(“Customer”)]
   public void CustomerStateChanged(object sender, StateChangedEventArgs args)
   {
      UpdateDataSources(args.NewValue as Customer);
   }

This way you can just use a property with the State attribute and get it updated when the State changes.

I’m also thinking of combining the StateAttribute and the StateChangedAttribute into one new attribute, but for now it works fine the way it is.