wpf - 我真的需要 MVVM 吗？

Question

不久前，我开始为 WPF 编写一个对接库(类似于 Avalon)。当时我的目标是使用 MVVM 方式进行学习。为了让事情顺利进行，我决定首先设计 View 和模型部分，并认为稍后我会在两者之间加入一些 View 模型。现在我完成了所有 View 和模型的工作: View 获取模型并直接与它对话，而模型公开一系列事件以盲目地通知它们的监听器。此外，它的每个视觉方面都可以在 XAML 中重新设置样式/模板。一切都很好。现在我被困在 View 模型部分。

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

我确实了解 MVVM 设计的优点并且我非常喜欢它，但在这种情况下，我看不到 View 模型如何为整个事物增加任何值(value)。

任何想法、建议或更正将不胜感激。

提前致谢。

Answer 1

这里的部分问题是您正在有效地制作一个控件库 - 因此，您正在开发的东西完全是 MVVM 中“ View ”的一部分。虽然您可能可以强制使用 MVVM 风格的“模型”来解决此问题，但它可能会混淆您的代码。

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

我并不是说干净地分离关注点没有值(value)，但在这种情况下，从 MVVM 的角度考虑这一点可能不太合适。 Model 与 View 没有分离，试图将其完全分离并在其间添加另一层抽象可能会增加复杂性而无济于事。

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

仅仅因为您正在使用 WPF 或 Silverlight 就自动假定 MVVM 是合适的，这是一种谬误。 MVVM 适用于某些类型的应用程序，但控件(或控件库)不一定是其中之一。