这是关于用户界面设计和编程模式的一般问题，尽管我的问题来自我正在开发的 WPF 应用程序。
当数据模型是分层的并且层次结构>时，呈现数据驱动的用户界面的干净、优雅的模式是什么？ 2层深？我所说的“最干净”是指一种只需很少的重复代码（而不是为每种数据模型类型编写表单）并且不需要太多繁琐的方法。例如，它可能依赖于反射。我想这就是我们有嵌套数据网格的原因。您可以将子对象嵌套在行详细信息模板中。几乎所有 LOB 应用程序都依赖于分层数据，因此肯定有人已经解决了这个问题。
但问题是，如果主网格有许多不同的子细节网格怎么办？用户界面可能看起来很混乱，细节网格嵌套在主网格中并相互堆叠。
我的一些想法可能是尝试嵌套在主网格中的选项卡控件。另一种方法是在新视图中打开一个新数据网格，并且不嵌套网格，但是再次为每个网格创建一个新视图似乎是我首先要避免的繁琐工作。
是否有更干净的替代方案可以通过分层结构构建“数据上的文本框”LOB应用程序除了逐一编码每个视图（和视图模型）之外，还有数据模型吗？
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 cleaner alternative to building a "text boxes over data" LOB application over a hierarchical data model besides coding each view (and viewmodel) one-by-one?
发布评论
评论（1）
从根本上来说，这是一个关于如何表示一棵树的问题。对此并没有太多良好的共识；这是一个棘手的问题。当然，嵌套数据网格的方法是有效的，但是当您将其描述为可能混乱时，您就击中要害了。
在某种程度上，这个问题的答案与当您在给定级别进行交互时需要多少有关树的其余部分的信息有关。当您处理两层以下的叶子时，您真的需要了解树的根以及根的所有子节点吗？当然，在某些用例中，您会这样做，在这些情况下，选择一种可以让您看到所有子级的表示结构是有意义的（如在嵌套网格方法中）。在其他情况下，您不需要了解太多有关树中更高级别的信息；在这些情况下，将较低数据的呈现隔离到其自己的呈现区域（页面）中是非常有意义的。
解决这个问题有各种不同的方法。您看过 prezi 吗？它非常令人印象深刻，而令人印象深刻的部分原因在于数据有一种“位置”感；它利用人类自己的空间感来帮助理解复杂的数据和层次结构；缩放确实锁定了空间方向感（有时会迷失方向）。
就您的实际问题而言；想想 REST，特别是 HATEOAS 期望。实际上，请考虑独立于演示文稿对数据进行建模，然后让演示文稿成为相对较薄的层，而不是密集的视图模型。可能有一些事情需要调整，但最重要的是，如果整体视图模型需要调整，您可以相对轻松地返回并修改它。同样，数据模型往往意味着对给定数据集有意义的某种结构。实际上，这是从数据中辨别结构并找到最适合该结构的显示模型的问题。通过不将大量工作提交给严格的视图模型，您可以根据需要进行更改。大致来说，敏捷 UI 设计。
这个东西非常主观，它实际上取决于您的组织和您的需求；对于每一种解决方案都没有一个好的答案。祝你好运;你至少问了正确的问题！
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!