DataSource for Entity Framework in WPF
DataSource for Entity Framework in WPF / Large Datasets: Virtual Mode
In This Topic
    Large Datasets: Virtual Mode
    In This Topic

    As mentioned in the Large Datasets: Paging|document=WordDocuments\C1DataStudio-WPF.docx;topic=Large Datasets\: Paging topic, Entity Framework DataSource (EF DataSource) has an even better solution than paging for dealing with large data and large numbers of rows.

    What if using large datasets with thousands, or even millions, of rows was no longer a problem? What if you could use the same controls to display massive datasets as you would for smaller datasets, with no paging, no code changes, and all by setting one Boolean property? With EF DataSource you can, thanks to the magical VirtualMode property.

    To implement virtual mode, follow these steps:

    1. Using the project we created to demonstrate Large Datasets: Paging|document=WordDocuments\C1DataStudio-WPF.docx;topic=Large Datasets\: Paging, add a new form with a C1DataSource component using the same ObjectContextType 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. Use the largest table in our sample database: Order_Details.
    3. Set the VirtualMode property to Managed.Another possible value is Unmanaged, but that is an advanced option that should be used with caution and only when necessary. The Managed option means that getting data from the server is managed by a grid control. With the Managed option, EF DataSource supports all main Microsoft and ComponentOne grid controls: C1FlexGrid, C1DataGrid, and Microsoft DataGrid for WPF . It is optimized for performance with those specific grid controls. The Unmanaged option means that virtual mode is not driven by a specific control, will work with any bound controls but is subject to some limitations described here|document=WordDocuments\C1DataStudio-ProgrammingGuide.docx;topic=Unmanaged virtual mode limitations.
    1. Add a grid to the designer and bind it to Order_Details the same way we did it before:

    ItemsSource="{Binding ElementName=c1DataSource1, Path=Order_Details}"

    1. Set the AutoGenerateColumns property of the grid to True in XAML.

    Now, since we selected the Managed option, we need to specify which grid control is driving the data. EF DataSource defines an attached property C1DataSource.ControlHandler|tag=P_C1_WPF_Data_Entities_C1DataSource_ControlHandler  that is an object having properties affecting the control’s behavior when it is bound to a C1DataSource|keyword=C1DataSource class. There is a boolean VirtualMode property in C1DataSource.ControlHandler|tag=P_C1_WPF_Data_Entities_C1DataSource_ControlHandler  that marks the control as the main, "driving" control in Managed virtual mode.

    1. Add the following inside the DataGrid markup in XAML (the added markup is shaded):

    <DataGrid AutoGenerateColumns="True"  Name="dataGrid1" 
           ItemsSource
    ="{Binding ElementName=c1DataSource1, Path=Order_Details}">
                <c1:C1DataSource.ControHandler>
                      <c1:ControlHandler VirtualMode="True"/>
                </c1:C1DataSource.ControHandler>

          </DataGrid>

    1. Save, build and run the application.

    You’ll see nothing earth-shattering, simply a grid you can navigate, scroll and modify row data as you see fit. It looks and behaves like any conventional data grid, which is precisely the point. Now you can use large datasets free of the drawbacks associated with paging, and all done without the need to write any code. And as an added benefit, you can use any GUI control you like so long as it has a DataSource property. This example has used a relatively modest-sized dataset, but C1DataSource running in virtual mode would be just as responsive with a much larger dataset; it does not depend on the number of rows. To further prove the point, look at the OrdersDemo sample installed with this product. The sample uses a larger database, with roughly 65,000 additional rows, but the responsiveness is the same as our example here. Again, it does not depend on the number of rows in the dataset.

    How does this magic work? It works much like paging, only hiding its inner workings from the GUI controls, with paging occurring under the hood. The GUI controls see the data as if it is fetched to the client and ready for them. When GUI controls request data, C1DataSource, or ClientViewSource if it is used in code without a C1DataSource control, first checks whether it can serve the data from memory, from the same client-side cache it uses for all features. If it can’t find it in memory, it transparently fetches the required data from the server. As with other features using the client-side cache, C1DataSource does not store the fetched data indefinitely, which would be a memory leak. It knows which parts of the data are needed for serving the GUI controls and which parts should be kept because they are modified or related to modified parts, and so on. It releases old, unnecessary parts of data as needed. No code is required and any GUI controls can be used.