This is a migrated thread and some comments may be shown as answers.

Best practice for multi-level Parent-Child data binding for RowDetails

1 Answer 239 Views
GridView
This is a migrated thread and some comments may be shown as answers.
BRiddle
Top achievements
Rank 1
BRiddle asked on 12 Jul 2011, 02:55 PM
I have a proof-of-concept WPF app with parent RadGridView with two hierarchical levels of child details.   Most of the information on the child detail of the top-level parent is in a child RadGridView.   That child grid's row details are mainly another RadGridView of the first child's children.    In the POC, all three grids were bound directly to VS2010-generated DataAdapters/Views.  That worked fine as long as only one top-level parent at a time had to display row details.

Now I find I need to instead have row details displayed at the same time for multiple parent rows in a RadGridView.   But if I simply source the child details out of the existing child dataset, then all parent table rows will show the child details for the same, currently selected parent row instead of being the unique child details which match each parent row.

I'd like to know what you recommend as the best practice for providing binding sources for child table-sourced row details to support multiple, simultaneous child row details displays.

I had thought about creating separate observable collections in the LoadingRowDetails event of the top two grids.  But with the parent grids' rows directly bound to DataAdapters/DataViews, there is no way to separate the data contexts with multiple top-level parent row details simultaneously opened.

I realize could do this by hand-creating three levels of custom business objects and sourcing their content from the database rows.   But I'd rather not start over like that if there is a decent solution leveraging at least part of the existing direct database data objects.  (All the current code for updating the database is directly using the bound DataSet/DataAdapter objects to automatically track the change deltas and perform the database updates).

What is the best practice here for providing multi-level row-details?   Should I just bite the bullet and change the app over to working off of three-level, hierarchical custom business objects, tracking my own change deltas, and hand-coding the database update logic?

Thanks for your thoughts,
-Bob

1 Answer, 1 is accepted

Sort by
0
BRiddle
Top achievements
Rank 1
answered on 12 Jul 2011, 10:17 PM
Thanks, those who viewed this thread.   But I ran out of time for figuring out how to best re-use the existing Adapter based code and began re-writing the app using EntityFramework objects extended to add the appropriate custom child properties that don't exist in the underlying tables.
Tags
GridView
Asked by
BRiddle
Top achievements
Rank 1
Answers by
BRiddle
Top achievements
Rank 1
Share this question
or