什么时候放弃 MVVM 才有意义？

Question

在学习 WPF 时，我一直专注于仅将 MVVM 模式应用于应用程序。

但是，我注意到对于某些功能such as validation，很难或不可能保持对 MVVM 模型的真实性。很多时候，只需将 x:Name 粘贴到元素上并在 code-behind event-handler 中更改它即可立即解决问题。

您在放弃 MVVM 模式方面有哪些实际经验？

• 什么时候放弃 MVVM 才有意义？例如您是否制定了规则，如果应用程序具有一定的复杂性，您将使用它，否则您不会？
• 什么时候放弃 MVVM 以后会削弱你（例如，我可以想象如果你想升级你的应用程序以使用复合应用程序库，注入 ViewModels 和容器的整个概念如果你所有的逻辑都在代码中
• 什么时候放弃 MVVM不重要，例如我可以想象，您不想/不需要测试的代码可以放在后面的代码中，而您的基本结构仍然是 MVVM 并通过模拟测试等运行。

Answer 1

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

Answer 2

我还没有遇到任何在 MVVM 之后无法做到的事情。有些事情是困难的，是的，但是一旦找到解决方案，困难就消失了。任何时候你遇到困难的事情，记住你在这个模式中的两个“大枪”：附加行为和服务。将这两个概念牢牢地控制在您的控制之下，您可以使用代码隐藏做任何事情，而您不能以一种更清洁、对 MVVM 友好的方式来做。这里最棘手的部分是找到最好的、最可重用的设计……但在任何代码中都是如此。

什么时候放弃 MVVM 才有意义？这取决于您对放弃的定义，但简单的答案是从不。如果您遇到了一个特定问题并且没有时间找到一个干净的解决方案，那么务实的做法是放弃针对那个问题领域的模式，而不是完全按照您的复杂性示例表明。

什么时候放弃 MVVM 会在以后削弱你？当您必须维护应用程序时。

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

Answer 3

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

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

因此，一方面，我知道严格遵循 MVVM 可能会很痛苦。

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

Answer 4

MVVM 只是一个建议。如果你不喜欢，你不必使用它。它声称的许多优势仍然需要证明。不过你总能从中借鉴一些好的想法。