我应该在 MVVM 的模型中使用 ObservableCollections 吗？答案

【问题标题】：Should I use ObservableCollections in the Model in MVVM?我应该在 MVVM 的模型中使用 ObservableCollections 吗？
【发布时间】：2017-02-26 02:02:44
【问题描述】：

我将 MVVM 用于表示模型并允许用户与之交互的 WPF 客户端。我一直避免在实际模型中使用 ObservableCollection 类（在该模型中选择像 IList 这样的通用集合，然后在底层集合更改时将该 IList 转换为 ViewModel 上的实际数据绑定 ObservableCollection）。原因是 MSDN 将该类呈现为 WPF 和以 UI 为中心：

您可以枚举任何实现 IEnumerable 的集合界面。但是，要设置动态绑定，以便插入或集合中的删除会自动更新 UI，集合必须实现 INotifyCollectionChanged 接口。这接口暴露了 CollectionChanged 事件，该事件应该是每当基础集合更改时引发。 WPF 提供 ObservableCollection 类，它是一个内置的实现实现 INotifyCollectionChanged 的数据收集界面。

问题：我的区别真的有必要吗？这是额外的工作和额外的代码。我知道这个主题对于 SO 来说可能过于模糊和主观，但也许每个人都遵循明确的、普遍认可的约定。

【问题讨论】：

标签： c# wpf mvvm observablecollection

【解决方案1】：

是的，我认为你做得对。 Observable 集合属于表示层。将它们添加到您的视图模型，而不是您的域模型。

This question may be of some help

但也许每个人都遵循明确的、普遍认可的约定。

找到后请告诉我，谢谢。

【讨论】：

好答案。这是你不能说绝对不的情况之一，但如果我在 MVVM 的模型中看到 ObservableCollection，这是一种非常强烈的“代码味道”。

【解决方案2】：

我的区别真的有必要吗？

这取决于在这种情况下模型的真正含义，或者更确切地说，取决于您如何定义模型。

如果它是在您的业务或服务层引用的程序集中定义的某种域业务对象，并且可以在您的整个域中使用，则它不应实现任何类型的客户端特定接口，例如INotifyCollectionChanged。

那么您应该更喜欢使用诸如IList 之类的泛型类型，然后在绑定到视图元素的客户端应用程序中创建一个包装类。

但如果模型是一个仅在您的客户端应用程序内部使用而不在您的应用程序的任何其他层中使用的类，那么您不妨将集合属性定义为ObservableCollection 并直接绑定到这个。

关键是域业务对象不应该了解 WPF 或客户端应用程序可能绑定到它的事实。这就是为什么直接绑定到 WPF 应用程序中的此类对象而不首先将它们包装在 WPF 感知视图模型类中很少有意义的原因。

这确实增加了一些额外的工作和一个额外的类，但同时它有助于保持关注点分离，这通常有利于维护。

在企业场景中，业务对象可能包含您不希望向客户端公开的业务逻辑，并且它还可能包含其他属性，这些属性向视图公开是没有意义的，这也是很常见的。因此，即使集合属性实际上应该返回 ObservableCollection，您仍然需要将其包装在另一个类中。

因此，如果您的问题是“我应该在业务对象中使用 ObservableCollections”，那么答案是否定的。

【讨论】：