为什么在使用 MVVM 时有一些代码用于执行简单的操作（例如打开或关闭对话框）是一个糟糕的设计选择？如果不是因为代码落后，那么处理这样一个简单问题（例如在 MVVM 中打开对话框）的一致性在哪里？
我知道这个主题可能已经被打死了，并且这些年来在 WPF 中使用“代码隐藏”已经得到了很多不好的代表。我只是想在这里表达我的观点，希望它可以帮助某人对这个问题有不同的看法。
我想大多数人都会同意 MVVM 模式虽然有点臃肿，但它鼓励重用和更好的可测试代码。将业务逻辑与视图分离并不是一个新概念，但许多人仍然不这样做。MVVM 和 WPF 通过数据绑定的概念使这种分离变得更容易一些，并允许您的 ViewModel 和业务逻辑独立于视图进行测试。
当开发人员需要做一些简单的事情（例如打开或关闭对话框）时，它就会崩溃。在 MVVM 之外，开发人员可以只实例化视图、分配 DataContext 并调用 ShowDialog。但是在 MVVM 中，开发人员的第一个想法始终是通过 MVVM 打开/关闭对话框的常见模式是什么。他们做了什么，他们将问题提交给 Google/Bing/StackOverflow。果然，他们找到了问题的答案，但问题是这里没有一致性来做这样一个简单的操作。有些人想使用调解器，有些人想使用对话服务，还有一些人想引入 Prism。几乎每个人都有自己的本土实施，所有人都要做些什么？这样他们就可以避免“隐藏代码”？对我来说这只是悲伤。我们' 我们基本上采用了一些简单易行的方法，并添加了抽象和间接来尝试解决问题。收益太小了，根本不值得。无需通过此级别间接，您仍然可以将您的 ViewModel 与其他 View 重用，并且您仍然可以单独测试您的 ViewModel。您唯一没有测试的是打开或关闭对话框的几行代码。
MVVM 和单元测试的纯粹主义者会认为这是亵渎神明。但请记住，最终，您要决定应用程序的复杂程度。对我来说，简单的解决方案通常是正确的解决方案。