当我学习MVVM模式时，我遇到了一个问题。我正在构建一个示例备注应用程序。在此应用程序中，您可以使用NotesView查看备注列表。 NotesView的DataContext是NotesModelView。
我的问题是NotesModelView是否应该包含NoteModel或NoteModelView（包含NoteModel）的集合？
答案 0 :(得分：2)
我总是将我的模型包装在视图模型中。这样，用户所做的任何更改仅应用于视图模型，而不应用于底层模型，直到用户想要提交这些更改（通过例如“保存”按钮），如果用户不想提交，您可以抛弃视图模型，从头开始，不要更改模型。这在处理数据库实体/对象时尤为重要，因为直接对实体进行的更改可能会很难回滚（至少如果您使用的是实体框架）
在某些情况下，“提交”是隐含的且上述内容不适用，但我仍然认为使用视图模型是一种好习惯，因为它还允许您对业务逻辑进行单元测试。 MVVM背后的主要动机是可维护性，并且具备良好的单元测试是实现这一目标的一种方式。
答案 1 :(得分：1)
我倾向于将所有模型类包装到视图模型中，所以我的一般答案是拥有一个包含NoteViewModel的{{1}}集合。
但我也是DRY principle的粉丝，所以在那些ViewModel根本不添加任何好处的情况下（例如我不需要重新格式化数据而且我不喜欢我需要更改通知，我不介意将原始模型暴露给视图）我有时会违反此规则。
由于您正在尝试学习MVVM，我对此特定案例的建议是使用一组viewmodels 。这将使您更好地了解MVVM，并在以后的应用程序中遇到此问题时帮助您进行这些区分。
答案 2 :(得分：1)
好的，你的命名有点令人困惑，我会选择一个更清晰的命名标准！人们通常使用“查看”来修改视图，并使用“ViewModel”查看模型。
所以在你的情况下，有一个NotesView，其DataContext是一个NotesViewModel。在NotesViewModel上，您应该有一个Notes集合（如果您希望将其称为NotesModel）。 NotesViewModel不应该有NotesViewModel的集合，因为这是不必要的，因为您可能只想在NotesView中显示Note数据。
答案 3 :(得分：0)
在您的示例中，您应该注意 - 作为模型，您应该定义Note的ObservableCollection类型，该列表将代表模型列表。 此列表将位于ViewModel中，您可以将其绑定到项目中的任何View