为什么在使用 MVVM 时，使用一些代码来执行简单的操作（如打开或关闭对话框）是一个糟糕的设计选择？如果不是代码隐藏，那么处理诸如在 MVVM 中打开对话框之类的简单问题的一致性在哪里？
我知道这个主题可能已经被打死了，多年来在 WPF 中使用"代码隐藏"得到了很多不好的代表。我只想在这里提出我的观点，希望它能帮助某人对这个问题有不同的看法。
我认为大多数人都会同意MVVM模式虽然有点臃肿，但鼓励重用和更好的可测试代码。将业务逻辑与视图分离并不是一个新概念，但许多人仍然没有这样做。MVVM 和 WPF 通过数据绑定的概念使这种分离变得更加容易，并允许独立于视图测试视图模型和业务逻辑。
当开发人员需要做一些简单的事情（例如打开或关闭对话框）时，它就会崩溃。在 MVVM 之外，开发人员只需实例化视图、分配 DataContext 并调用 ShowDialog。但在 MVVM 中，开发人员首先想到的始终是通过 MVVM 打开/关闭对话框的常见模式。他们做什么，他们把他们的问题带到谷歌/必应/StackOverflow。果然，他们找到了问题的答案，但问题是做这么简单的操作没有一致性。有些人想使用调解器，有些人想使用对话服务，有些人想引入棱镜。几乎每个人都有自己的本土实施，并且都完成什么？这样他们就可以避免"代码隐藏"？对我来说，这太可悲了。我们基本上采取了一些简单的事情，并添加了抽象和间接来尝试解决问题。收益太小了，甚至不值得。如果不经历此级别的间接寻址，您仍然可以将视图模型与其他视图重用，并且仍然可以单独测试视图模型。您唯一无法测试的是打开或关闭对话框的几行代码。
MVVM 和单元测试纯粹主义者会认为这是亵渎神明。但请记住，最终，这实际上是您决定要使应用程序变得多么复杂。对我来说，简单的解决方案通常是正确的解决方案。
为什么在使用 MVVM 时，使用一些代码来执行简单的操作（如打开或关闭对话框）是一个糟糕的设计选择？
事实并非如此，任何告诉你的人都不了解 MVVM 的核心目标。
如果不是代码隐藏，那么处理诸如在 MVVM 中打开对话框之类的简单问题的一致性在哪里？
有关特定问题的一致性不是像 MVVM 这样的通用模式可以或需要提供的。没有正确的方法可以做到这一点，除其他方面外，还有违反MVVM的方法和不违反MVVM的方法。