我目前正在努力争取WPF MVVM的使用-我的意思不是让我的想法成为现实，而是围绕实际工作中的实际要点而不是愚蠢的CRUD做些超越常规的事情。

我注意到的是，很多框架以及大多数/所有博客文章都来自“时代”。

这是因为现在已经过时了，而博客作者已经转向Next Next Thing，还是仅仅因为他们已经说了所有要说的话？

换句话说，我这里缺少什么吗？

MVVM并不是过时的，但是从一开始它就被夸大了。我从不喜欢它，它使我在WinForms中呆了太久；我没看见森林里有树木，所以把婴儿和洗澡水一起扔了出去。我现在有了WPF，我的想法是不希望将代码与标记混合使用，但是我更喜欢Android风格，即将标记放在一个地方，然后在代码中使用强制类型转换（甚至在WPF中也可以使用）尽管出于任何原因这样做从来没有变得时尚）。

这样，您可以获得更细粒度的控制，而不必担心到处都是“不变的”处理。我觉得这实际上是更可测试的，因为如果您错过“未更改”的事件，测试将不会总是抓住它。

您失去了一些“声明式”的性质，这似乎是当今的一种趋势（例如，如果将两个小部件映射到相同的值，则在MVVM中您可以做到这一点，而使用命令式代码则必须分别设置两者） 。但是即使使用MVVM，也只能在特殊情况下使用。如果某个窗口小部件必须显示另一个窗口小部件的日志，则必须编写另一个处理程序和另一个“ onchanged”事件，因此最终您不得不对“ declarative”的定义进行扩展。

2015年更新

WPF MVVM在当时是（进化）的。和WPF一样。但是他们都有疣。普通WPF内置了太多内容（加上它是建立在XML之上的），很难处理。（的确，如果WPF只是采用了更多的“库”方法而不是“框架”方法，它可能会变成一些非常酷的东西，并且整个技术领域现在可能会完全不同）。MVVM 的想法很棒，但是尝试将MVVM装入WPF有点困难，因为1）C＃在没有很多样板的情况下无法真正表达它，以及2）模态弹出窗口之类的WinForms遗物在意识形态上仍然很普遍，但不能易于在MVVM中表示。因此，这一切都糟透了。

也就是说，当您需要透明性或LOB应用程序的GPU时，它仍然是Windows上唯一可行的选择。

React当然使MVVM过时了。令我感到失望的是，VS2015没有与之相反的本地功能。现在，我们仍然停留在使用原始WPF（可以，但是感觉很老（真的感觉和winforms 一样老），并且没有大量内置功能（感觉像一些很酷但被放弃的项目）或使用MVVM，这点似乎没有任何开销，因为即使是良好的 MVVM（角度1）也因其缺点而暴露在外。

我会避免使用WPF MVVM。这是一个额外的层，没有人关心它了。

综上所述，使用MVVM框架可以做的事情是有限的。

由于WPF自微软发布以来一直没有进展，因此它们是“完成的”。如果对该技术进行了更新，则这些库也将需要更新。这还没有发生。