I forgot to answer your final question about MVVM. I'm open to anything that that keeps my UI out of my view-model and keeps anything non-UI out of my code behind (I'm not so religious as to say nothing can be in code-behind).

For example, providing a command property that automatically passes through a special stream that can be consumed by your exporters. Here's off the top of my head to give you an idea...

<telerik:RadGridView ... ExportCommand={Binding ExportCommand, Mode=OneTime} .../>

...

ExportCommand = new DelegateCommand(async data => await ExportDataGridAsync(data));

...

async Task ExportDataGridAsync(object data)

{

if (data is GridViewStream gridStream) {

var provider = new XlsxFormatProvider();

// create stream (e.g. to create a file) and whatever else

await provider.ExportAsync(gridStream, stream);

}

}

Yoan,

It mainly ties together and most of the clunkiness I was referring to has to do with the hoops to get the hierarchical data. (I hated the process enough that to do what I wanted I created a special exporter class using your XlsxFormatProvider. I could easily invoke it through a command in my view-model. It was more involved, but it wasn't cryptic and it was MVVM.)

I'll go into some detail. Right now, in order to export you have to either use an event handler to capture the RadGridView in your code-behind, or you have to pass its reference to your view-model thereby leaking UI implementation. At that point, it's simple enough to create your stream and call the Export method. It's just not graceful for MVVM. The real clunkiness comes into play if you want to capture your hierarchical data. At that point, you need to add a handler for the ElementExported event where you capture the context for the child grid and then export it's contents. It's a very non-MVVM approach.

Anthony