在WPF中，MVVM模式是最好的模式吗？有什么缺点吗？
5个回答
26
这篇博客文章简短精要地介绍了MVVM的优缺点，出自John Gossman (*)本人之手。
他认为其主要缺点是：
"对于简单的UI，M-V-VM可能有些过度设计。在更大的情况下，很难事先设计好ViewModel以获得足够的通用性。虽然数据绑定拥有许多奇妙之处，但它是一种声明式的方式，比起仅需设置断点的流畅命令式方式来说更加难以调试"
John Gossman的博客是该模式的原始来源，他也是负责“发明”该模式的团队的架构师。
- Reed Copsey
3
1约翰·戈斯曼是谁？ - Shridutt Kothari
3@shriduttkothari 的博客是这种模式的原始来源 - 他是负责“发明”这种模式的团队的架构师 :) - Reed Copsey
1哇，太好了，知道这个。那么我认为这个信息应该明确地在你的回答中提到，而不仅仅是对于不知道这个名字的人。因为有些人可能不会阅读这些评论。干杯！！ - Shridutt Kothari
7
为了建立我们的应用程序，我们开始使用MVVM，但是由于以下原因我们放弃了MVVM：
继承问题
我们使用C#编程，并且希望使用继承。C#不支持多重类继承，因此我们无法拥有包含部分在UI中重复使用逻辑的抽象类。
大多数情况下，我们都会感到困惑，如何设计视图模型以便我们可以继承并控制逻辑。
如果我们继承View，则同时无法继承ViewModel；如果我们继承ViewModel，则同时无法继承View。相反，我们必须使用非常复杂的泛型，并借助像Prism和Unity这样的工具来实现，但这不值得花费时间。 ViewModel到ViewModel绑定 大多数时候，业务逻辑并不像A = B + C那么简单，UI和UI上的响应起着重要作用。然而，我们可以将UI的可视属性绑定到视图模型的数据属性，但问题在于如何将一个视图模型实际绑定到另一个视图模型上，如果它们通过共享控件的两个绑定，则我们无法确定将首先执行什么。 ViewModel不是代码后台的简单替代 人们认为ViewModel是代码后台文件的简单替代。但是，在制作我们的应用程序时，继承约束告诉我们，正如WPF / Silverlight支持完全将UI与逻辑分离的UI样式一样，我们只是在ViewModel中过度分离业务逻辑。 ViewModel中的重复代码 我们最终意识到，在每个视图和每个视图模型中，我们只是编写相同的代码模式，更改这些代码模式变得非常麻烦，维护也很麻烦。MVVM更适合测试驱动开发，但是当涉及编写可扩展组件时，它们不是最佳选择。
WPF / Silverlight已经非常好地将代码和UI分离，我们现在设计了非常简单的类层次结构，执行业务逻辑并为我们提供所需的一切。我们现在将所有基于ICommand的命令属性创建为我们类的依赖属性，在UserControl和Templated Control中进行绑定。
CodeBehind中的ICommand或ResourceDictionary中的Template and Styles为我们提供了几乎可以获得的所有MVVM优点。
大多数情况下，我们都会感到困惑，如何设计视图模型以便我们可以继承并控制逻辑。
如果我们继承View，则同时无法继承ViewModel；如果我们继承ViewModel，则同时无法继承View。相反，我们必须使用非常复杂的泛型，并借助像Prism和Unity这样的工具来实现，但这不值得花费时间。 ViewModel到ViewModel绑定 大多数时候，业务逻辑并不像A = B + C那么简单，UI和UI上的响应起着重要作用。然而，我们可以将UI的可视属性绑定到视图模型的数据属性，但问题在于如何将一个视图模型实际绑定到另一个视图模型上，如果它们通过共享控件的两个绑定，则我们无法确定将首先执行什么。 ViewModel不是代码后台的简单替代 人们认为ViewModel是代码后台文件的简单替代。但是，在制作我们的应用程序时，继承约束告诉我们，正如WPF / Silverlight支持完全将UI与逻辑分离的UI样式一样，我们只是在ViewModel中过度分离业务逻辑。 ViewModel中的重复代码 我们最终意识到，在每个视图和每个视图模型中，我们只是编写相同的代码模式，更改这些代码模式变得非常麻烦，维护也很麻烦。MVVM更适合测试驱动开发，但是当涉及编写可扩展组件时，它们不是最佳选择。
WPF / Silverlight已经非常好地将代码和UI分离，我们现在设计了非常简单的类层次结构，执行业务逻辑并为我们提供所需的一切。我们现在将所有基于ICommand的命令属性创建为我们类的依赖属性，在UserControl和Templated Control中进行绑定。
CodeBehind中的ICommand或ResourceDictionary中的Template and Styles为我们提供了几乎可以获得的所有MVVM优点。
- Akash Kava
2
1自从我最初提出问题以来已经过了一段时间。在这段时间里，我在我的工作项目中大量使用了MVVM。所以，使用继承时，您想要一个同时从View和ViewModel继承的类？这个类是View还是ViewModel？使用服务和任何类型的IOC可以解决ViewModel中重复的代码。我同意ViewModel绑定和“ViewModel不仅仅是CodeBehind”。 - Cameron MacFarland
服务和IOC在中型应用程序中非常复杂。最糟糕的是，在小团队中它们太难调试和管理。尽管它有优点，但对于年轻人来说，它还是太过复杂了。 - Akash Kava
7
- Daniel Auger
5
"SRP America的后背痣在这个图案中是干燥的" 这是什么意思？我已经试着读了三遍。 - oligofren
我的意思是，这种模式倾向于在不同层中的外观相似的对象之间具有属性重复（这是2009年思考DRY违规的潜在问题，当时我回答了这个问题）。它这样做是为了使对这些对象的任何更改仅限于需要该更改的层。这个问题是在人们通常将他们的领域模型直接绑定到UI的日子里回答的，不可避免地会发生UI所需与后端逻辑所需之间的冲突，这是SRP的味道。 - Daniel Auger
1@oligofren - 在重新阅读您的评论后，我想知道您是否运行了一个浏览器插件，将某位前美国总统的名字变成了无意义的话语。 - Daniel Auger
1哈哈，你说得对！那个揭示真是尴尬。我在另一个浏览器上读了你的评论，一下子就明白了。我已经忘记了几年前安装这个插件了：https://chrome.google.com/webstore/detail/trump-be-gone/hdogoomobiommmfeekbmnmcogakplogm - oligofren
只是想指出，MVVP在SPA /前端世界中也有最近的复兴，使人们能够测试所有渲染逻辑，而不需要任何对React库的引用。这是一个启示 :) - oligofren
5
是的，对于小型的hello world风格的应用程序来说，这确实有些过度。
- Mehrdad Afshari
1
43没有真正存在 - Brian Leahy
1
不同的模式有不同的优势。人们往往会把模式和实现混淆在一起。业务逻辑的排列或访问方式对于哪种模式更适合于给定应用程序具有影响力。因此，虽然这个问题是关于WPF的，但阅读关于在任何框架中使用三种模式实现相同屏幕三次的文章可能会有所帮助。
下面是一个链接到Java文章的链接，它比较了MVVM（“演示模型”）与MVP（“被动视图”）以及混合实现MVVMP/MVC（“监督控制器”）。我认为这与这个问题相关，因为其中有一个部分对模式进行了比较。
它指出了John Gossman所提出的弱点，但也对两种替代模式的优缺点进行了比较。
- simbo1905
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接