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

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

但是，我注意到，对于某些功能而言，很难或不可能保持MVVM模型的真实性。很多时候，只需在元素上粘贴一个x:Name，并在事件处理程序后面的代码中更改它即可立即解决问题

您在放弃MVVM模式方面有什么实际经验

• 放弃MVVM什么时候有意义？e、 g.您是否制定了规则，如果应用程序具有某种复杂性，您将使用它，否则您不会使用它
• 什么时候放弃MVVM会让你以后陷入困境（例如，我可以想象，如果你想升级你的应用程序以使用复合应用程序库，如果你把所有逻辑都放在代码后面，那么注入ViewModels和容器的整个概念将不起作用
• 什么时候命名MVVM无关紧要，例如，我可以想象，当您的基本结构仍然是MVVM并通过模拟测试运行时，您不想/不需要测试的代码可能就在代码后面

---

我没有放弃MVVM模式，因为我从未完全应用过它
由于历史背景的原因，我的公司仍然使用C原生库，封装在托管库中，用于C#和WPF程序。绑定无法使用，某些行为（如INotifyPropertyChanged）无法实现，因为更改是在某些深层C方法中完成的……重构如此之深是不可取的
因此，一方面，我理解严格遵循MVVM可能会很痛苦

---

另一方面，我认为MVVM是WPF的一种好模式，应该尽可能多地使用。
我认为代码隐藏只要与视图相关就可以了。它不会破坏MVVM，因为层的分离很重要。如果您的VM不知道视图，那么我认为使用XAML或代码也没关系。您尽量减少代码隐藏，因为在XAML中通常更干净、更容易操作，但有时几行代码比很多XAML更干净。例如，绑定键盘上的所有键。您可以在XAML中键入101键绑定或5行代码。
我还没有遇到任何在MVVM之后无法完成的事情。有些事情是的，很难，但是一旦找到了解决方案，困难就消失了。每当你遇到困难的事情，记住你的两个“大炮”在这种模式中：附加的行为和服务。这两个概念牢牢掌握在您的控制之下，您对codebehind所做的任何事情都不能以更干净、MVVM友好的方式完成。这里的棘手部分只是找到最佳、最可重用的设计……但这在任何代码中都是正确的
放弃MVVM什么时候有意义？这取决于你对放弃的定义，但简单的答案是永远不要。如果你有一个具体的问题要解决，没有时间找到一个干净的解决方案，那么务实的做法就是放弃这个问题领域的模式，而不是全部正如您的复杂性示例所示
什么时候放弃MVVM会使您以后陷入瘫痪？什么时候您必须维护应用程序

---

什么时候简化MVVM无关紧要？演示/示例程序、一次性/简单实用程序等等。
MVVM只是一个建议。如果你不喜欢，你就不必使用它。它声称的许多优点仍然需要证明。但你可以从中借鉴一些好的想法。
务实，而且反应公平。然而使用代码后面的问题只是简单地把代码放在那里是不应该的。如果你/你的团队有纪律去做这件事，那就去做吧。不过我不认为这是最好的练习。我想你的意思是附加的行为，如乔什史密斯的例子：“服务”是什么意思？关于MVVM，如本文所述？现在有两种“附加行为”。一种是传统的方式，如Josh的文章所述，另一种是新的方式，具有混合行为。新方式是可工具化的，但我们使用旧方式已经有一段时间了。至于服务，我指的是服务定位器和/或依赖项注入。参见Onyx（）（免责声明：我是作者）。