MVVM模式有哪些问题？

Question

Model-View-ViewModel是WPF中使用的最佳模式吗？有什么缺点吗？

Answer 1

这是一篇关于MVVM优缺点的好短文博客,直接来自John Gossman本人.

他的主要缺点是:

"对于简单的用户界面,MV-VM可能过度.在较大的情况下,为了获得适当的通用性,可能很难预先设计ViewModel.所有奇迹的数据绑定都是声明性的,比调试更难.你只需要设置断点的绝佳命令"

Answer 2

为了构建我们的应用程序,我们从MVVM开始,但在遇到很多问题之后我们放弃了MVVM,因为以下原因可以确定哪些不使用MVVM.

继承问题

我们用.NET编程,我们使用C#,最好我们确实需要继承.C#不支持多类继承,因此我们不能使用具有部分在UI和逻辑中重用的逻辑的抽象类.

大多数时候我们都很困惑,如何设计View Models以便我们可以继承和控制逻辑.

如果我们继承View,我们不能同时继承ViewModel,如果我们继承ViewModel那么我们就不能同时继承View.相反,我们必须使用非常复杂的泛型,并且在Prism和Unity等工具的帮助下我们可以实现,但它不值得花时间.

ViewModel到ViewModel绑定

那么大多数时候业务逻辑都不像A = B + C这样简单,UI和UI上的响应很重要.但是我们可以将UI的可视属性绑定到View Model的数据属性,但问题是如何将一个视图模型实际绑定到另一个视图模型,如果它们通过共享控件的两个绑定,那么我们不知道将执行什么第一.

ViewModel并不是CodeBehind的简单替代品

假设ViewModel是CodeBehind文件的简单替换.但在制作我们的应用程序时,对继承的限制告诉我们,因为WPF/Silverlight支持可以完全将UI与逻辑分离的UI样式,我们只是在ViewModel中分离业务逻辑.

ViewModel中的重复代码

我们最终意识到我们只是在每个View和每个ViewModel中编写相同的代码模式,这会改变一个巨大的痛苦,而且维护也是一种痛苦.MVVM更适合于测试驱动开发,但是当涉及编写可扩展组件时,它们不是最佳候选者.

WPF/Silverlight已经让你非常好地分离代码和UI,我们现在确实设计了非常简单的类层次结构,它执行业务逻辑并为我们提供所需的一切.我们现在创建所有基于ICommand的命令属性作为我们的类的依赖属性,我们在UserControl和模板控件中绑定.

CodeBehind中的ICommand或ResourceDictionary中的模板和样式为我们提供了几乎所有可以通过MVVM获得的好处.

Answer 3

这是一个很好的模式,坦率地说是WPF为数不多的刷新UI模式之一.我的意思是,许多人理解并采用了它.因此,获得帮助和信息相对容易.

我认为最大的缺点是它增加了应用程序中类和组件的数量,因为SRP在这种模式中胜过DRY.话虽如此,我认为这是值得的.

Answer 4

是的，这对于小型 hello world 风格的应用程序来说有点过分了。