Silverlight for Developers (Part II)
Join the DZone community and get the full member experience.Join For Free
In Case You’ve Just Tuned In…
In my previous post, I talked about Visual Studio vs. Expression Blend, styles, and templates. In this post I’ll talk about databinding.
The Ties That Bind
As with WPF, databinding is an incredibly powerful feature of Silverlight. The ability to declare a relationship between properties of an element and the properties of an object is amazing. You can bind the properties of Silverlight controls to any CLR object’s public properties, but it will be a one-time binding only. Ideally, you’d probably like it if a Label would update when its associated property changes. In order to get dynamic binding, you need to be able to alert the controls when the value changes. Fortunately, you can do this without even tying your object to Silverlight itself.
Enter the System.ComponentModel.INotifyPropertyChanged interface. This interface signals to consumers that this object raises the NotifyPropertyChanged event whenever a public property’s value changes. This event simply references the sender (the object itself) and a strong representation of the property name. In every property’s setter method you can raise the event. WPF will automatically subscribe to any objects that implement this interface. It will bind to an object without the interface – it will just be one-time.
If you have a collection of objects, you may want elements like ListBoxes or ComboBoxes to reflect changes to the collection’s elements. For this purpose, use the ObservableCollection class as the base. This is like using the List class, but it automatically raises events for added and removed elements. Coupled with INotifyPropertyChanged, your UI can be completely responsive to object changes.
You will also hear about Dependency Properties. These are a special type of property that are used for UI elements. In this case, properties are accompanied by DependencyProperty objects that can be passed around to refer to a property without using reflection. These property values are potentially dependent on the values of other objects, such as size which can be affected by scaling, rotation, and layout. This is a somewhat more advanced topic to understand, although implementing them is pretty straight-forward.
Taking it in Context
Once you have an object or collection for binding, you don’t actually need to explicitly bind that object to every field. For example, if you have fields for name, address, and city, you’ll need to set a binding for each to the Name property, Address property, and City property, but the question of the source object is settled by using the DataContext property of a parent. Data context works as a hierarchy. When an element is bound to a field name, like Address, it has no idea of where it will find that data except to check its DataContext. If no object is set there, it will check the context of its containing object, and so on up the chain. This makes for a very powerful arrangement that makes it easy to move UI elements around or even pull them out to a new user control with minimal rework.
To Be Continued
In my next post, I’ll talk about how you can write code to perform special tasks, while keeping your code-behind work to a minimum…
Published at DZone with permission of Arian Kulp. See the original article here.
Opinions expressed by DZone contributors are their own.