背景：
我正在处理WPF解决方案，该解决方案没有按照MVVM模式进行良好的分离。我需要改善架构，可读性等。
我当前的问题是我的MainVM具有大量依赖关系。 MainVM对应于MainWindow视图。 MainVM在启动时创建，并将应用程序的所有其他ViewModel保留为属性。该MainVM传递给所有Commands调用（实现ICommand的调用），并且如果某些功能需要其自己的ViewModel，它将引用MainVM并读取包含所需ViewModel的相关属性。
另一个问题是ViewModels没有与Models分离。
我的想法是为ViewModels创建一个“存储”（理想情况下是Model，但是此时很难实现分离），并从该存储而不是从MainVM访问所需的ViewModel。
我的应用程序不存储任何内容，因此此ViewModels存储的生存期将与应用程序的生存期相同（静态）。
现在我的问题（措辞）：
1-从一个“主” ViewModel访问ViewModel是常见的做法吗？
2-在WPF应用程序中对ViewModels和Models使用单独的存储可能有哪些弊端？
3-命令（实现ICommand的命令）是否应该依赖于ViewModels？
表述问题：
1-将视图模型存储在WPF应用程序中的什么位置？
2-是否可以使用存储库模式在WPF中存储模型？
3-无修改
答案 0 :(得分：2)
1-从一个“主” ViewModel访问ViewModel是常见的做法吗？
回答：否。这是一个非常糟糕的设计（如果我称之为设计）。视图模型 设计时应使其与父代无关 子级，这样即使将来更改其层次结构也不会 影响任何其他模块。它应该只处理属性， 命令，它支持的视图事件。与任何通讯 子视图或父视图模型应通过事件发生。这应该 绝对不通过直接引用父或子VM的属性 参考。这样，您将拥有可维护，可测试的应用程序，并且 不会碰到您现在所处的状况。
2-在WPF应用程序中为ViewModels和Models使用单独的存储可能有哪些缺点？
回答：我假设存储是指ViewModel通过其属性和命令向View公开的Model对象。理想情况下，该模型应该是应用程序的业务对象。请注意，根据视图设计和功能，单个ViewModel可以具有多个模型。但是，您永远都不应从模型访问VM，我认为这暗示了您的问题。如果您不是不必要地将您的观点细分为微型 拥有无数个赞模型和视图的视图应该没问题。
3-命令（实现ICommand的命令）是否应该依赖于ViewModel？
回答：命令的编写方式也应尽可能 重用于视图中的类似操作。