将通用 ViewModel 功能推入基类？答案

【问题标题】：Push common ViewModel functionality into a base class?将通用 ViewModel 功能推入基类？
【发布时间】：2009-11-15 21:05:59
【问题描述】：

我将 MVVM 与 Prism 和 Silverlight 一起使用。我对一个模型有多种不同的看法。当我写更多视图时，他们的 ViewModel 似乎重复了很多与处理这个模型相关的通用代码。与其在所有虚拟机中重复相同的通用代码，我更倾向于将其推回模型中（这可能会过多地混淆关注点）。或者可能是一些常见的 ViewModel 基类？或者我的虚拟机可能需要它们和模型之间的第二级“共享虚拟机”？这个单一的共享实例，二级虚拟机将整合多个常规虚拟机共享的行为和状态。

有没有关于这些问题和可能的方法的cmet？

感谢 cmets 伙计们。我可能应该告诉你更多关于有问题的特定“共享”虚拟机代码。

我可以看到将一些未来代码放在 VM 基类中，但我正在查看的特定“共享”代码似乎属于由实现的 INotifyPropertyChanged模型本身。这部分基于other thread。

我不认为这违反了 SoC，因为该模型本质上是动态的。它的某些属性仅在特定时间有效。模型的动态特性不仅对 UI 很重要，适当的单元测试也会关心它。因此这个模型似乎需要一个 INotifyPropertyChanged。

有什么相关的吗？

【问题讨论】：

@Alan Cobb，所有这些是怎么回事？标题中的标记？

标签： silverlight mvvm viewmodel

【解决方案1】：

如果公共代码可以由所有 ViewModel 共享，那么值得将其放入基本 ViewModel 类型中。

如果公共代码仅由与特定模型交互的 ViewModel 共享，那么“共享”的 ViewModel 就是要走的路。

【讨论】：

【解决方案2】：

我已经成功地在New York Times Silverlight Kit 中使用了 ViewModels 的继承来减少重复的代码。以 CommunityRecentComments 及其父类 CommunityBase 为例。

【讨论】：

【解决方案3】：

各种 MVVM 框架中的大多数“基本 ViewModel”类都倾向于包含对 INotifyPropertyChanged 的支持，并且通常对分派回 UI 线程提供某种支持。

除此之外，我认为如果您有许多 ViewModel 共享功能，这些功能应该放在一个基类中，那么我使用这种模式的次数越多，我发现自己使用的 ViewModel 层次结构就越浅，代码的基本 ViewModel对所有视图模型通用，通常是另一个基类，用于 UI 的该区域中的通用功能。通常是常用命令或 UI 共享元素的地方。

ViewModelBase -> ProductsViewModelBase -> NewProductViewModel

【讨论】：

【解决方案4】：

在完全是 MVVM 的 SoapBox Core 中，我定义了一个 IViewModel 接口和一个 AbstractViewModel 基类，正如 Nigel 所说，它只是实现了 INotifyPropertyChanged。（请注意，SoapBox Core 是 WPF，而不是 Silverlight，但在这种情况下，这没什么大不了的。我也做过一些类似的 Silverlight 工作。）

然后我定义了更多从 IViewModel 继承的接口（如 IMenuItem）和更多提供这些接口基本实现的抽象类。

现在，这说明了整个 ViewModel 树，但正如您所说，还有模型树。我现在已经花了将近一年的时间与 MVVM 合作，这是我最大的顿悟：不要编写模型。如果您从头开始构建应用程序，只需将所有内容都放在 ViewModel 中，否则您最终会复制大量代码。

唯一让我烦恼的情况是，当我使用未实现 INotifyPropertyChanged 并因此不容易绑定的 3rd 方库时。我相信实体框架的自动生成代码也可能在这里，但我注意到一些实体框架现在让您可以选择在实体本身中实现 INotifyPropertyChanged。

说真的，我们应该将它重命名为 ViewModel 模式并完成它。 :)

【讨论】：