MVVM 标准化

Question

某人在 Silverlight posted MVVM 目前缺乏标准化，所以每个人都有自己的风格..

这就是为什么我和 WPF Disciples 的一些人正在积极讨论每个人都同意的 MVVM 元素。我完全理解我们以不同的方式实现了模式，我们混合了几种模式或根据我们项目的需要或为了让开发人员的生活更轻松创建我们自己的模式..但是忘记那些困难或项目的特殊需要.我们来讨论一下大家都同意的MVVM模式的标准规则。我发了 some of my thoughts here以及。

为什么是 MVVM？

可测试性(ViewModel 比代码隐藏或事件驱动代码更容易进行单元测试)

用户体验设计师和开发人员之间的明确分离

增加 View 的“可混合性”

模型永远不需要更改以支持对 View 的更改

ViewModel 很少需要更改以支持对 View 的更改

没有重复的代码来更新 View

在 View 中做和不做

不应包含您要测试的任何逻辑:正如 Glenn 所说，MVVM 不是代码计数练习，我们可以在代码隐藏中编写代码。但是您永远不应该编写任何要测试的逻辑。例如:如果用户选择一个国家，那么您希望在您的 View 中显示州或城市列表。这是业务需求，因此您应该进行单元测试来测试此逻辑。所以，你不应该在代码隐藏中编写它。

可以是控件或数据模板

保持 View 尽可能简单。 :我们仍然可以小心地在 XAML 中使用数据触发器或值转换器或可视状态或混合行为。

如果某些内容不可绑定(bind)，请使用附加属性:

在 ViewModel 中做和不做

View 和模型之间的连接器

保持 View 状态，值转换(您可以创建要在 ViewModel 中显示的数据结构，而不是使用 ValueConverter。例如:您需要显示名称而不是名字和姓氏。您的模型可以有名字和姓氏Name 但您可以在 ViewModel 中创建 Name 属性。)

View

没有强或弱(通过接口(interface))引用

使 VM 尽可能可测试(例如，不调用 Singleton 类)

VM 中没有与控制相关的东西(因为如果您要更改 View ，那么您也必须更改 VM。)

型号

可以是数据模型、DTO、POCO、域类的自动生成代理和 UI 模型，具体取决于您希望如何在域服务和表示层之间进行分离

没有引用 ViewModel

你对此有什么建议或意见吗？

我们小组中有一个分歧。有人说ViewModel里面有View的接口(interface)就可以了。但有人说，如果View Model有View的接口(interface)，那就是MVP模式。

我们的一位 MVVM 专家谈到 MVVM 与 MVP

View => View 模型

MVVM View 直接绑定(bind)到 ViewModel 并通过数据绑定(bind)与 VM 对话

在 MVP 中， View 绑定(bind)到悬卡在 SupervisingController 上的模型或根本不绑定(bind)(被动 View )。

View 模型 => View

MVVM

INPC/属性(property)绑定(bind)

事件

消息(事件聚合器/信使/RX 框架)

通过服务等中介

通过接口(interface)

通过委托(delegate)(View 将委托(delegate)传递给 VM，它可以使用它来回调它。例如，VM 可能公开一个 SetActions 方法，View 调用该方法传递它委托(delegate)。

MVP

在 MVP 的情况下，标准是 Presenter 通过接口(interface)、数据绑定(bind)或在被动 View 的情况下通过属性与 View 进行对话。使用被动 View ，属性不使用数据绑定(bind)，而是使用 View 属性 getter 和 setter 直接设置控件值。

你怎么看这个想法？

你认为ViewModel有View的接口(interface)就可以了吗？

如果您想添加更多，欢迎您添加... :)

关于这篇文章的整个想法是在社区中获得对 MVVM 模式的相同理解。

Answer 1

我喜欢你写的东西。真正让我感到困扰的一件事是，很多人似乎将他们的 VM 与他们的 View 紧密耦合 - 如果您这样做，那么您可能只是在做旧的 XAML + 一切都被打入了背后的代码中.

我使用的模式在 MVVM 上略有不同(但大致相同)。就我个人而言，我喜欢将我的 ViewModel 作为界面提供给 View - 它使分离非常干净。这在做原型(prototype)时有很多好处，视觉元素可以在 View 中切入或切出，对 ViewModel 影响很小或没有影响。