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

Question

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

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

问题：我的区别实际上是否有必要？这是额外的工作和额外的代码。我明白这个话题可能对于SO来说太模糊和主观，但也许每个人都有明确的，普遍公认的约定。

Answer 1

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

This question may be of some help

但也许有明确的，普遍商定的约定每个人都遵循。

请让我知道，当你找到他们，THX。

Answer 2

我的区别实际上是否有必要？

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

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

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

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

问题是，域业务对象不应该有任何WPF知识或客户端应用程序可能绑定到它的事实。这就是为什么在WPF应用程序中直接绑定到这些对象而没有将它们首先包装在WPF感知视图模型类中是很有意义的。

这确实增加了一些额外的工作和额外的类，但同时它有助于保持这通常是很好的维护问题分离。

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

所以，如果你的问题是“我应该用ObservableCollections在业务对象”的答案是否定的。