InMemoryDataProviderWrapper: Data Provider on Steroids

The InMemoryDataProvider has been around for a long time. I’ve written about it here before. However, there is one important limitation: this provider does not support relations that do not result from key fields. You can’t simply “pack” XML into it; it’s only suitable for “flat” formats like CSV or XLS. However, the basic technology has been around for a long time. When I discovered this customer wish in our Idea Place, it sparked the idea of extending this technology to cover any data provider structures.

The result is the InMemoryDataProviderWrapper. Using it is very simple:

// The RestDataProvider or the SchemaAwareJsonDataProvider are also suitable here
XmlDataProvider provider = new XmlDataProvider(@"c:\temp\text.xml");
using (ListLabel LL = new ListLabel())
{
// the wrapper around the XML provider is created here. This one line is the only change
InMemoryDataProviderWrapper wrapper = new InMemoryDataProviderWrapper(provider);
LL.DataSource = wrapper;
LL.Design();
}

The highlight: wrapping doesn’t change the structure, i.e. the project files that have already been created for the XML can remain unchanged. The test XML for this blog post is from here. Previously, without the wrapper, sorting wasn’t available. Now, sorting can be selected with an otherwise completely identical structure:

Another option is working with native filters:

A selection of native aggregate functions is also available:

The provider uses the least amount of memory possible – tables are only loaded into memory when they’re actually needed. This means there’s no complete caching of the (possibly very large) file, but caching on demand. And if the features are no longer needed at some point, the wrapper can be removed at any time without having to change the project files.

Thank you very much for the suggestion in the Idea Place. I’m happy about this new member in our data provider zoo.