Elegant UI pattern for building LOB apps over hierarchical data?

This is a general question on user interface design and programming patterns, even though my question comes from a WPF application I'm working on.

What is a clean, elegant pattern to present a data-driven user interface when the data model is hierarchical and the hierarchies are > 2 levels deep? By cleanest, I mean an approach that takes very little repetitious code (versus coding a form for every data model type), and requires little tedium. It might rely on reflection, for example. I guess this is why we have nested data grids. You could nest the child objects in the row details template. Nearly all LOB apps rely on hierarchical data, so someone must have solved this problem already.

But the problem with this is, what if the master grid has many different child detail grids? The user interface can look cluttered with detail grids, nested into the master grid and stacked on top of each other.

Some ideas I had might be to try a tab control, nested in the master grid. Another is to just open a new data grid in a new view and don't nest the grids, but then again creating a new view for every grid seems like the tedious work I'm trying to avoid in the first place.

Is there a clean开发者_开发知识库er alternative to building a "text boxes over data" LOB application over a hierarchical data model besides coding each view (and viewmodel) one-by-one?

Fundamentally, this is a question about how to represent a tree. There's not a lot of good consensus on this; it's a tricky issue. Certainly, the approach of nested data grids is valid, but you hit the nail on the head when you describe it as potentially cluttered.

To some extent, the answer to this question has to do with just how much information about the rest of the tree you need when you're interacting at a given level. Do you really need to know about the root of the tree, and all of the children of the root, when you're working with leaves two levels down? There are certainly use cases where you do, and in those cases, it makes sense to choose a representational structure that lets you see all of the children (as in your nested grid approach). In other cases, you don't need to know much if any information about higher levels in the tree; in those situations, it makes perfect sense to isolate the presentation of lower data into its own presentation area (page).

There's all sorts of different approaches to just this problem. Have you seen prezi? It's very impressive, and part of what makes it impressive is that there's a sense of "place" to the data; it's using human's own spatial sense to help make sense of complicated data and hierarchies; the zooming really locks in that sense of spatial orientation (occasionally dis-orientation).

In terms of your actual question; think of REST, and specifically of the HATEOAS expectation. In effect, consider modeling your data independent of the presentation, and then letting the presentation be a relatively thin layer, as opposed to a dense viewmodel. There might be some things that need tweaking, but most importantly, if the overall viewmodel needs tweaking, you can go back and modify it relatively easily. As well, the data model tends to imply a certain structure that makes sense with a given data set; effectively, it's a matter of discerning structure from your data, and finding the display model that most appropriately fits that. By not committing boatloads of work to a strict viewmodel, you get the ability to change as necessary. Agile UI design, roughly.

This stuff is very subjective, and it really depends on your organization and your needs; there's no one good answer for every solution. Good luck; you're at least asking the right questions!