我可能会因此而复杂化。我现在已阅读了几个教程，但不明白。
我知道可观察的集合被映射到模型项列表。
Model
List family
View model
Observable collection families(model.families)
但我现在读了两件事：
数据上下文始终指向视图模型对象。
可观察的集合应该是视图模型的集合
因此我的困惑。如果视图上的组合框绑定到族列表，然后选择一个族，则其余控件将用于该族的详细信息...
我理解视图模型属性角色的概念是模型数据和视图数据之间的机制。并且每个房产都有所改变。
但是如果你的模型有一个家庭对象列表，你如何构建一个可观察的familyviewmodels集合？
如果有更合适的地方可以问这个，那么请指导我，我会删除这个问题。
我认为ObservableCollection (model.families)是正确的。然后将值绑定到所选组合对象的成员。它确实有效。但根据我的阅读，我觉得我有一些不正确的事情如上所述。
感谢您缓解我的头痛。
答案 0 :(得分：1)
在我看来，你的问题至少部分是“基于意见”。因此，您可以更好地在http://programmers.stackexchange.com或http://codereview.stackexchange.com上征求意见。请注意，如果您选择后者，则必须构建一个好的Minimal, Complete, and Verifiable code example，以清楚地说明您的问题，并提供与该代码示例相关的问题。
但是如果你的模型有一个家庭对象列表，你如何构建一个可观察的familyviewmodels集合？
您没有在此处提供任何代码示例，因此无法提供任何准确的指导。但是，肯定没有什么可以阻止您创建代理FamilyViewModel对象的Family，就像您的ObservableCollection<Family>代理Family个对象列表一样。然后，您可以改为使用ObservableCollection<FamilyViewModel>。
这就是我在你的问题中看到的“实际编程问题”的程度，即这将使其成为主题。也就是说，只要我在评论，我就会指出设计模式旨在使代码更易于编写和维护。如果你发现试图遵循设计模式强加的教条会妨碍良好的，可维护的代码，那么现在是时候放弃那个特定的教条，至少在那个特定的时刻。
特别是，我发现“视图模型”和“模型”之间的界限可能很模糊。在某些情况下，程序主要是与用户的交互，而视图模型就是所需要的。在其他情况下，程序主要是业务逻辑，编写一个全新的视图模型只是为了包装现有的业务逻辑数据结构是过度的。
关注点的分离可能是有用的，例如当您需要与其他需要完全脱离UI的组件进行交互时，或者您希望能够测试UI代码而不必依赖于某些昂贵且难以重建的业务逻辑数据结构。但是不要让这个概念束缚你的手。如果您有一个简单的数据结构，可以通过例如直接映射到UI元素基于列表的控件的模板，我认为直接使用该数据结构作为“视图模型”没有任何问题。
当然注意到，有些人会不同意我的立场，在某些情况下会强烈反对。因此，你的问题的“基于意见”的性质。可以说这是一个在这里关闭的问题。恕我直言，如果你想要更好和更客观的回答，你应该用一个好的MCVE提出你的问题，并把你的问题集中在该代码示例的某些特定的方面，可以用客观的方式解决（例如例如关于如何将业务逻辑数据结构映射到视图模型兼容的数据结构的问题。）