WPF Binding vs Event Handling

Question

I'm new to WPF and come from a WinForms background and have a fairly basic question about binding vs event handling.

To try and maintain some separation of responsibility I've have a bunch of presentation objects which simply have dependency properties to hold the UI data parts of a business object, the business object contains similar data but the data types are occationally different so that the Presenation object is correct for display purposes. So something like

public class MyPresentation
{
   // bunch of dependency properties
   public bool MyProperty
   {
      get { return (bool)GetValue(MyPropertyProperty); }
      set { SetValue(MyPropertyProperty, value); }
   }

   // Using a DependencyProperty as the backing store for MyProperty.  This enables animation, styling, binding, etc...
   public static readonly DependencyProperty MyPropertyProperty =
   DependencyProperty.Register("MyProperty", typeof(bool), typeof(MyPresentationObject), new UIPropertyMetadata(false, MyPresentationObject.MyPropertyPropertyChanged));

   MyBusinessObject RelatedBusinessObject { get; set;}

   public MyPresentation(MyBusinessObject businessObejct)
   {
      this.RelatedBusinessObject = businessObject;
   }


   public static void MyPropertyPropertyChanged()
   {
      // Do some stuff to related business objects
   }
}

The properties of MyPresentation are then data bound to various controls and I use triggers etc to change presentation dependency properties which causes business object changes in the OnPropertyChanged event. The question I have is am I using binding in the correct fashion? Normally (in Winforms) i'd have used click events etc to change my business objects (or the presentation versions of them) values but those sort of events and that sort of event handling seems superfluous now that you can use binding, triggers and OnPropertyChanged events.

Am I missing something?

Answer 1

I reckon you're on the right track, as DependencyProperties have built in mechanisms for handling change they get rid of that extra layer of event handling - well it's still there but it's built into WPF.

BTW - I'm sure someone will have some MVC wisdom to make everything even simpler though.

Answer 2

You are correct in using the bindings this way. Also check out the Model View View-Model pattern as it is similar to what you are doing but a more definable template. Also check out the interface INotifyPropertyChanged - this is a more accepted way of trapping that a property has changed locally and notifying the view (your form) that an object has changed. That way you get the best of both worlds: changes to objects might happen as the result of a button click, or from bindings.

Answer 3

Hi Michael,

In my experience the normal pattern is to simply use a presentation/business object that implements INotifyPropertyChanged.

There is rarely a need to implement your business/presentation object as a DependencyObject or with attached DependencyProperties because data binding in WPF only requires one side of the binding to be a DependancyObject (in this case your Controls) - the other side can, and in the case of business objects, usually should be a POCO. Otherwise you end up having to contaminate your business objects with WPF classes unnecessarily.

Also making your objects DependencyObjects is probably overkill because you wont be animating, styling, templating their values etc.

Cheers, Jack

Answer 4

Look here this present the pattern Model View ViewModel, this permit you to take full advantages on the binding, and Command of WPF, without disturb your business objects (like implementing WPF stuff like INotifyPropertyChanged on your business objects)

Answer 5

You are writing extra code you don't need to write.

First, if the presentation object just passes the values along you can bind directly to the business object and cut out the middleman.

Second, you don't need dependency properties on the presentation object, styling and animation on business objects just don't make sense and you can "plug into" the UI -> presentation object just by writing normal everyday setters for your properties.

In your example the use of dependency properties only gets you automatic presentation object -> UI updates, as everyone here wrote you can get this with simpler code by using INotifyPropertyChanged.