放弃MVVM什么时候有意义？

Question

在我学习WPF的过程中，我一直专注于只将 MVVM模式应用于应用程序。

但是，我注意到对于某些功能such as validation ，很难或不可能保持MVVM模型的真实性。很多时候只需在元素上添加 x：Name 并在代码隐藏事件处理程序中更改它就可以立即解决问题。

您对放弃MVVM模式有什么真实的体验？

• 什么时候放弃MVVM才有意义？例如您是否制定了规则，如果某个应用程序具有某种复杂性，您将使用它，否则您将不会使用它？
• 什么时候放弃MVVM 稍后瘫痪（例如，我可以想象如果你想升级你的应用程序以使用Composite Application Library，注入ViewModels和Container的整个概念将无效
背后的代码中包含所有逻辑
• 什么时候放弃MVVM 无关紧要，例如我可以想象你不需要/需要测试的代码只能在代码中，而你的基本结构仍然是MVVM并且通过模拟测试等运行。

Answer 1

如果仅与视图相关，我认为代码隐藏很好。它不会破坏MVVM，因为它是层次分离的重要因素。如果您的虚拟机不知道视图，那么我认为使用XAML或代码并不重要。您尝试最小化代码隐藏，因为它通常更简洁，更容易在XAML中执行，但有时几行代码比许多XAML更清晰。例如，绑定键盘的所有键。您可以在XAML中键入101个键绑定或5行代码。

Answer 2

我还没有碰到任何跟随MVVM无法做到的事情。有些事情是困难的，是的，但一旦找到解决方案，困难就消失了。每当你遇到困难的事情时，请记住这种模式中的两个“大枪”：附加的行为和服务。由于这两个概念牢牢掌控在您的控制之下，因此您无法以更清晰，更友好的MVVM方式执行代码隐藏。这里棘手的部分就是找到最好的，最可重复使用的设计......但在任何代码中都是如此。

放弃MVVM什么时候有意义？这取决于你放弃的定义，但简单的答案是永远。如果你有一个特定的问题，你正在努力并且没有时间找到一个干净的解决方案，那么务实的事情就是放弃那个问题领域的模式，而不是完全如此你的复杂性例子表明。

什么时候放弃MVVM会让你瘫痪？当你必须维护应用程序时。

什么时候放弃MVVM无关紧要？演示/示例程序，丢弃/简单实用程序等。

Answer 3

我没有放弃MVVM模式，因为我从未完全应用它！

由于历史背景，我公司仍然使用C本机库，封装在托管库中，用于C＃和WPF程序。无法使用绑定，并且无法实现某些行为，例如INotifyPropertyChanged，因为更改是在某些深层C方法中完成的...重构如此深刻不是一种选择！

所以一方面，我明白MVVM严格遵循可能会很痛苦。

另一方面，恕我直言，我认为MVVM是一个很好的WPF模式，应该尽可能多地使用。

Answer 4

MVVM只是一个推荐。如果你不喜欢，你不必使用它。它声称的许多优点仍然需要证明。但是你可以随便借用它的一些好主意。