我真的需要MVVM吗？

Question

不久前，我开始为WPF编写一个停靠库（类似于Avalon）。当时我的目标是用MVVM方式进行学习。为了让事情运行起来，我决定先设计视图和模型部分，并认为我稍后会在其间插入一些视图模型。现在我完成了所有的视图和模型：视图获取模型并直接与它交谈，而模型公开了一系列事件以盲目地通知他们的听众。此外，它的每个视觉方面都可以在XAML中进行重新设置/模板化。事情进展顺利。现在我被困在视图模型部分。

由于这种库的性质（内容更改并动态重新创建），还有很多代码仍然需要在视图的代码隐藏部分中编写，我并没有真正看到它的好处还必须为每个视图编写一堆视图模型类。可能在几个地方使用一些绑定/命令会很方便，但我并不认为它弥补了完成纯MVVM设计所需的所有重构。

我确实理解MVVM设计的优点，我非常喜欢它，但在这种情况下，我看不到视图模型如何为整个事物增加任何价值。

非常感谢任何想法，建议或更正。

提前致谢。

Answer 1

这里的部分问题是你正在有效地创建一个控制库 - 因此，你正在开发一些完全属于MVVM中“View”的东西。虽然你可以强制推出一个MVVM-ish“模型”，但它可能会使你的代码变得混乱。

请记住，MVVM旨在将特定于应用程序的逻辑和数据连接到View - 但在这种情况下，当您编写控件库时，您的“逻辑和数据”就是View本身。将视图与模型分开在这里没有多大意义 - 因为模型实际上已经是视图的一部分了。

我并不是说清楚地分离关注点并不重要，但在这种情况下，在MVVM方面考虑这一点可能不太合适。模型并不与View分开，并且尝试将其完全分离并在其间添加另一层抽象可能会增加复杂性而无法获得。

如果您正在制作自定义控件库，那么目标不应该是使用MVVM编写它，而是确保在MVVM应用程序中使用时控件可以正常工作。这通常意味着确保您的控件都为所有内容和设置公开适当的依赖属性，并且它们可以干净地使用数据绑定等。事实上，事件通常不是必需的，至少没有那么多，并且具有单独的“模型类”层次结构将阻碍用户 - 用户希望能够放弃您的控件并直接绑定到该控件上的属性 ，这几乎可以保证您的控件具有代码背后。

因为你正在使用WPF或Silverlight而自动假设MVVM是合适的是一个谬论。 MVVM适用于某些类型的应用程序，但控件（或控件库）不一定是其中之一。

Answer 2

如果代码背后有很多代码 - 你没有以正确的方式使用MVVM，大多数事情都可以用MVVM方式完成 - 通过使用Bindings或Commands在View或ViewModel中实现。

  

我没有看到视图模型如何为整个事物添加任何值。

ViewModel提供：

• 模型本身，ViewModel经常封装模型本身（当不需要在同一个ViewModel中替换不同的模型时）
• 由udnerlying模型公开的数据（因为ViewModel绑定到View的DataContext，而不是amodel本身）
• 命令处理逻辑
• 简化View生活的标志 - 例如公开bool IsValid之类的标志，以便View可以呈现绿色背景而不是红色（简化为显示逻辑封装和责任委派）

Answer 3

我看到它的方式，View Model旨在扩展您的模型以迎合您的UI，而不会让您使用一堆特定于UI的代码弄乱您的模型。如果您的模型是按照定义设计用于UI构造的对象，那么它确实满足了模型和视图模型的角色，并且没有必要在设计中添加另一层。

Answer 4

我总是理解你的模型就是数据，就是这样。没有方法或类似的东西（我甚至不在我的模型中实现INPC）

视图模型的目的是以友好的方式向View显示数据。所以你永远不应该直接绑定到模型数据，总是绑定到View Model上的数据。

我所做的就是拥有我的模型，让我们说模型是一类Person，它只会保存值而已，如果我想使用这个类来绑定那么我会创建它的一个实例我的模特。但是，如果它需要INotifyPropertyChanged，我将创建一个DVM（数据视图模型），它包含Person类的实例，并具有在person类中获取/设置数据的属性，但在需要时也会引发INPC。该类还包含我可能需要的任何UI特定数据。

所以我的MVVM实现看起来像

模型＆gt; DVM（可选）＆gt; ViewModel＆gt;查看

视图永远不会直接与模型对话，只能通过viewModel。

我也觉得应该尽可能地避免使用良好的MVVM。

回答你的问题是MVVM需要吗？可能不是很好但我发现MVVM应用程序非常容易理解和维护。

我认为你在这里使用MVVM的问题可能只是你接近设计的方式。我总是在创建视图的同时创建我的空视图模型类，这样看起来它似乎不是一件大事。