I'm developing a wpf-based application and I'm currently struggling to find the best way of supporting a recurring scenario in it.
This app uses grids a lot. There are a bunch of features I want in it that are meant to be used in grids, such as drag & drop, multiple row edition, conditional row coloring, etc. But at the same time, I want my data objects to derive from a specific, data-oriented class that is unaware of any UI context and could be used by a single form, with standalone editors.
Therefore, I'd like to have a
DataGridViewModel class that will in turn expose two collections:
DataGridColumnViewModel. The row view model would expose a
RowData property which will be the actual data object, while the column view model would have a
System.ComponentModel namespace) that will indicate which data object field the column is meant for.
You can think of the
DataGridRowViewModel as a container for the "real" row object.
The goal is to allow separation of concerns between grid-specific functionalities (controlling row height, color, selection, etc) and data-specific functionalities, so that one doesn't need to know about the other. Ideally, a third component will be aware of both and ensure proper communication between the two layers (observing a data field and change the row color under condition x or y, for example).
Does this approach makes any sense? What kind of complications should I expect out of this (binding issues, performance and the likes)?