为什么在使用MVVM时执行简单操作（例如打开或关闭对话框是一个糟糕的设计选择）后面会有一些代码？如果不是代码背后，那么处理这样一个简单问题的一致性在哪里，比如在MVVM中打开一个对话框？
我知道这个话题可能已经被打死了，并且在WPF中使用“Code Behind”这些年来已经变得很糟糕。我只是想在这里说明我的观点，希望它有助于某人对问题有不同的看法。
我认为大多数人会同意MVVM模式虽然有点膨胀，但却鼓励重用和更好的可测试代码。将业务逻辑与视图分离并不是一个新概念，但许多人仍然不这样做。 MVVM和WPF通过数据绑定的概念使这种分离更容易，并允许您的ViewModel和业务逻辑独立于视图进行测试。
它崩溃的地方是开发人员需要做一些简单的事情，比如打开或关闭对话框。在MVVM之外，开发人员可以实例化视图，分配DataContext并调用ShowDialog。但是在MVVM中，开发人员首先想到的是通过MVVM打开/关闭对话框的常见模式。他们做了什么，他们将问题提交给Google / Bing / StackOverflow。当然，他们找到了问题的答案，但问题是这里做一个简单的操作没有一致性。有些人想要使用Mediators，有些人想要使用对话服务，有些人则希望使用Prism。几乎每个人都有自己的本土实现，所有这些都是为了完成什么？这样他们就可以避免出现“Code-Behind”？对我而言，这只是悲伤。我们基本上采取了一些非常简单的事情，并添加了抽象和间接来试图解决问题。收益很小，甚至不值得。如果不通过此级别间接，您仍可以将ViewModel与其他视图一起重用，您仍然可以单独测试ViewModel。您唯一没有测试的是打开或关闭对话框的几行代码。
MVVM和单元测试纯粹主义者会认为这是亵渎神灵。但请记住，最终，您决定要制作应用程序的复杂程度。对我来说，简单的解决方案通常是正确的解决方案。
答案 0 :(得分：1)
为什么在使用MVVM时执行简单操作（例如打开或关闭对话框是一个糟糕的设计选择）后面会有一些代码？
不是，任何告诉你的人都不理解MVVM的核心目标。
如果不是后面的代码，那么处理这样一个简单问题的一致性在哪里，比如在MVVM中打开一个对话框？
关于特定问题的一致性不是MVVM可以或需要提供的一般模式。没有正确的方法可以做到这一点，除了其他方面之外，还有违反MVVM的方式和不违反MVVM的方式。