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

Question

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

  

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

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

Answer 1

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

This question may be of some help

  

    

但也许每个人都有明确的，普遍认同的约定。

  

当你找到它们时请告诉我。

Answer 2

  

我的区别是否真的有必要？

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

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

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

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

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

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

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

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