So far, we have simply dealt with the object. However, this is not the only source of data; XML and the associated database that you suddenly think of are popular choices. Further, due to XML or
The related database does not store data as. NET objects, some transformations may need to support data binding, as you would expect, on a data source object. NET properties. And even if we can declare objects directly in XAML, we still want a layer to indirectly pull data from other sources, even handing this work to a working thread, if retrieving is a stiff operation.
In short, for object conversion and loading, we want indirect rather than direct declarative means. For this indirect approach, we must focus on the implementation of the IDataSource interface, one of which is the data object source.
4.4.1 Data Object Source
One implementation of the IDataSource interface is to provide an indirect layer for all operations that generate the object to bind to. For example, if we want to load a group of person objects on the web, we need to enhance the logic in some code, such as example 4-34.
Example 4-34
namespace PersonBinding {
public class Person : INotifyPropertyChanged {}
public class People : ObservableCollection<Person> {}
public class RemotePeopleLoader : People {
public RemotePeopleLoader( ) {
// Load people from afar
}
}
}
In example 4-34, the Remotepeopleloader class derives from the People Collection class and retrieves data in the constructor, because the object data source expects it to create a collection, as in example 4-35.
Example 4-35
<Window.Resources>
<ObjectDataSource
x:Key="Family"
TypeName="PersonBinding.RemotePeopleLoader"
Asynchronous="True" />
</Window.Resources>
<Grid DataContext="{StaticResource Family}">
<ListBox ItemsSource="{Binding}" >
</Grid>