To show large amounts of data without bringing it all to the client at once, Web applications have traditionally used paging. Paging is not an ideal solution; it complicates the interface and makes it less convenient for the user, but it is preferred in some applications. For these cases, C1DataSource supports paging as expected, but it does so without the traditional limitations on data modification. The user can make changes in multiple pages in one session without being forced to send the changes from one page to the database before moving to the next page. That’s a substantial enhancement compared to other paging implementations, such as the one in the standard RIA Services DomainDataSource.
Note: ComponentOne Studio for Entity Framework (SEF) does offer a solution to the drawbacks of paging; we'll cover virtual mode later in this documentation.
To implement paging, follow these steps:
1. Using the project we created to demonstrate Master-Detail Binding, add a new form with a C1DataSource component using the same DomainContextTypeName as before. Note that you can make this the startup form to save time when you run the project.
2. Create a ViewSource in the ViewSourceCollection editor and select GetOrders in the QueryName property.
3. To enable paging, set the PageSize property to 10 for now, but you can choose any reasonable value for this property. It’s simply determining the number of data rows that will be displayed on a page.
4. Add a DataGrid and bind it to Orders the same way we did it before:
ItemsSource="{Binding [GetOrders], ElementName=c1DataSource1}"
5. Set the AutoGenerateColumns property of the grid to True in XAML.
6. To allow the user to move between pages and to show the current page and page count, add two buttons and a label using, for example, the following XAML:
<StackPanel Orientation="Horizontal" Grid.Row="1" Margin="10">
<Button Padding="10,0,10,0" Margin="1" Content="<" Click="MoveToPrevPage"/>
<TextBlock VerticalAlignment="Center" Text="Page: "/>
<TextBlock VerticalAlignment="Center" x:Name="pageInfo"/>
<Button Padding="10,0,10,0" Margin="1" Content=">" Click="MoveToNextPage"/>
</StackPanel>
7. Add the following code containing a RefreshPageInfo handler for the PropertyChanged event used to show current page number and page count, and handlers for the buttonClick events used to move to the next and previous pages:
Imports C1.Data.DataSource
Partial Public Class Paging
Inherits UserControl
Private _view As ClientCollectionView
Public Sub New()
InitializeComponent()
_view = c1DataSource1("GetOrders")
RefreshPageInfo()
AddHandler _view.PropertyChanged, AddressOf RefreshPageInfo
End Sub
Private Sub RefreshPageInfo()
pageInfo.Text = String.Format("{0} / {1}", _view.PageIndex + 1, _view.PageCount)
End Sub
Private Sub MoveToPrevPage_Click(sender As System.Object, e As System.Windows.RoutedEventArgs) Handles MoveToPrevPage.Click
_view.MoveToPreviousPage()
End Sub
Private Sub MoveToNextPage_Click(sender As System.Object, e As System.Windows.RoutedEventArgs) Handles MoveToNextPage.Click
_view.MoveToNextPage()
End Sub
End Class
•C#
using C1.Data.DataSource;
namespace TutorialsSilverlight
{
public partial classPaging : UserControl
{
ClientCollectionView _view;
public Paging()
{
InitializeComponent();
_view = c1DataSource1["GetOrders"];
RefreshPageInfo();
_view.PropertyChanged += delegate { RefreshPageInfo(); };
}
private void RefreshPageInfo()
{
pageInfo.Text = string.Format("{0} / {1}",
_view.PageIndex + 1, _view.PageCount);
}
private void MoveToPrevPage(object sender, RoutedEventArgs e)
{
_view.MoveToPreviousPage();
}
private void MoveToNextPage(object sender, RoutedEventArgs e)
{
_view.MoveToNextPage();
}
}
}
8. Save, build and run the application.
Notice there is an empty Customer column in the grid. This is because we only fetch Order objects without associating them with Customer objects. This can be rectified by using the [Include] attribute, as we did in Master-Detail Binding.
9. In the DomainService1.cs, add the Include operator to the query in the GetOrders method:
Return Me.ObjectContext.Orders.Include("Customer")
•C#
return this.ObjectContext.Orders.Include("Customer");
10. In the DomainService1.metadata.cs, add the [Include] attribute before the corresponding property:
<Include()>
Public Property Customer As Customer
•C#
[Include]
public Customer Customer { get; set; }
11. Run the project and page through all of the Orders. While you are moving between pages, try changing some data in the grid. Try changing data in one page, then move to another page and try changing data there. Notice that C1DataSource allows you to do this without forcing you to save data to the database before leaving the page. This is an important enhancement compared with other paging implementations, including the one supported by DomainDataSource in Microsoft RIA Services (which is for Silverlight only, whereas SEF supports this, as other features, for all three platforms: WinForms, WPF, Silverlight).
Try to delete some orders. This is also allowed without restrictions, and moreover, the current page will automatically complete itself to keep the number of rows in the page unchanged.
And if you add a SaveChanges button as we did above, using the following handler, then you will be able to save changes made in multiple pages by pressing that button when you are done.
Private Sub btnSaveChanges_Click(sender As System.Object, e As System.Windows.RoutedEventArgs) Handles button1.Click
c1DataSource1.ClientCache.SaveChanges()
End Sub
•C#
private void btnSaveChanges_Click(object sender, RoutedEventArgs e)
{
c1DataSource1.ClientCache.SaveChanges();
}
All this functionality is what you would expect from a paging implementation that supports unrestricted data modification. Unfortunately, it is not easy to implement.
For example, think of all possible cases where changing data on one page interferes with what should be shown on other pages, and so on. That is why paging usually imposes severe restrictions on data modifications, if they are at all allowed. For example, MS DomainDataSource requires you to save all changes before changing pages. Fortunately, SEF supports paging without restricting data modifications in any way.
As with many other features, unlimited modifiable paging is made possible by the client-side cache, see The Power of Client Data Cache. That also means that paging implementation in SEF is optimized both for performance and for memory consumption. The cache provides that optimization. It keeps recently visited pages in memory, so re-visiting them is usually instantaneous. And it manages memory resources, releasing old pages when necessary, to prevent memory leaks.