wpf - 重构臃肿的 ViewModel

Question

我正在编写 PRISM/MVVM/WPF 应用程序。这是一个LOB应用程序，所以有很多复杂的规则。我注意到 View 模型开始变得臃肿。有两个主要问题。

其中之一是为了维护 MVVM，我做了很多感觉很奇怪的事情，比如向我的 VM 添加一堆属性。 View 绑定(bind)到这些属性以跟踪 View 特定信息的感觉。例如， bool 值跟踪 VM 中长时间运行的进程的状态，因此 View 可以在长时间运行的进程运行时禁用其某些控件。我读到这个问题可以通过附加行为来解决。我会进一步研究这一点。在您在线看到的示例 MVVM 应用程序中，这并不是什么大问题，因为它们过于简化了。

另一个问题是我的虚拟机中的命令数量。现在有四个命令。我使用 Josh Smith 的 RelayCommand(基本上是 PRISM 中的 DelegateCommand)在 VM 中定义命令，因此所有业务逻辑都位于 VM 中。我考虑将每个命令移至单独的工作单元中。我不确定执行此操作的最佳方法。

你们使用哪些模式来保持虚拟机干净？我已经感觉到有人回应“你的 View 和虚拟机太复杂，你应该将它们分成许多 View /虚拟机”。从用户体验的角度来看，它当然不会太复杂 - 有 2 个按钮、一个组合框和一个列表框。此外，从逻辑角度来看，它是一个有凝聚力的领域。话虽如此，我很想听听其他人如何处理此类问题。

感谢您的投入。

Answer 1

我感受到你的痛苦。在开发 MVVM 应用程序时，我经常遇到此类问题。有一天，我会发布一份问题 list ，以获取像您一样的其他人的意见。

我非常担心 ViewModel 基类中的“膨胀”，但在具体的 ViewModel 子类中却不太担心。将 2-3 个 ViewModel 使用的依赖项放入基类中通常很诱人，但应该避免。

虽然我不能假设知道你对臃肿的想法是什么，但我可以说我不认为在虚拟机中处理“繁忙”属性或命令是不好的。您可能需要考虑的一件事是 ViewModel 是否可以同时忙于执行多件事。如果是这样，您可能需要继续思考如何打破它。虽然我个人没有在实践中见过它，但您可能可以将单个、内聚的 View 和几个 ViewModel 绑定(bind)到它。

如果您的命令很长，或者它们可以在不同的目标上执行，我认为使命令自动执行单元是一个好主意。但最好与这种方法保持一致，以避免让以后使用它的任何人感到困惑。例如，如果您有一个大约有 10 行代码的 SaveCustomerCommand 类，您可能不想将 RelayCommand 用于其他所有内容。

如果对这类东西有硬性和快速的规则，那就太好了，但我认为框架和模式现在仍处于进化阶段。