MVVM模式的问题是什么?[关闭]

这是一篇关于 advantages and disadvantages of MVVM 直接从约翰·戈斯曼本人。

他的主要缺点是:

“对于简单的用户界面,m-v-v m可能是杀伤力过大的。在更大的情况下,为了获得适当的通用性,很难预先设计视图模型。对于所有奇迹来说,数据绑定都是声明性的,而且比设置断点的命令式的东西更难调试。”

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

继承问题

我们在.NET中编程,并且使用C并且我们最希望继承。C不支持多类继承,因此我们不能拥有逻辑部分在UI和逻辑中重用的抽象类。

大多数时候我们都很困惑,如何设计视图模型以便继承和控制逻辑。

如果继承视图,则不能同时继承视图模型;如果继承视图模型,则不能同时继承视图。相反,我们必须使用非常复杂的泛型,借助棱镜和统一等工具,我们可以实现,但这不值得花时间。

视图模型到视图模型绑定

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

ViewModel不是简单的代码隐藏替换

假设viewModel只是简单地替换代码隐藏文件。但是,在制作我们的应用程序时,对继承的限制告诉我们,由于WPF/Silverlight支持可以完全用逻辑分离UI的UI样式,所以我们在ViewModel中过度分离业务逻辑。

ViewModel中的重复代码

我们最终意识到,我们只是在每个视图和每个视图模型中编写相同的代码模式,改变这一模式会带来巨大的痛苦,维护也会带来痛苦。MVVM更适合测试驱动的开发,但在编写可扩展组件时,它们不是最佳的候选者。

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

codebehind中的icommand或resourcedictionary中的template和styles为我们提供了可以从MVVM获得的几乎所有好处。

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

我认为最大的缺点是它增加了应用程序中类和组件的数量,因为 SRP 王牌 DRY 在这种模式下。尽管如此,我认为这是值得的。

是的,对于小型Hello World风格的应用程序来说,这是一种过度杀伤力。

不同的模式有不同的优势。人们往往将模式与实现混淆。业务逻辑的排列或访问方式对给定应用程序更自然的模式有影响。因此,尽管这个问题询问有关WPF的问题,但在任何框架中阅读三次用于简化同一屏幕的三种模式可能会有所帮助。

下面是一个Java文章的链接,它将MVVM(“演示模型”)与MVP(“被动视图”)和混合实现MVVMP/MVC(“监视控制器”)进行比较。我相信这与这个问题有关,因为它有一个章节,对模式进行比较。

Implementing event-driven GUI patterns using the ZK Java AJAX framework

它指出了约翰·戈斯曼的弱点,但同时也将优势和弱点与两种不同的模式进行了比较。