严格分离视图和模型的好处？答案

【问题标题】：Benefits of strictly separating View and Model?严格分离视图和模型的好处？
【发布时间】：2017-03-11 05:21:58
【问题描述】：

我的一位同事不想从视图直接绑定到模型。例如，在模型中，他有一个 ObservableCollection，而在视图中他想使用它。而不是像我那样直接使用它（例如{Binding Model.Collection}，他在 ViewModel 中有另一个 ObservableCollection，它与模型中的 ObservableCollection 具有完全相同的数据。他通过事件将两个 ObservableCollection 相互同步。

他的方法有什么好处？我个人不赞成他的方法，因为它只是添加了重复的代码，而且由于您必须自己同步 ObservableCollections，所以它也更容易出错。我的同事说他想这样做，因为这样他就可以在不更改视图的情况下更改模型。

编辑：

一些高度赞成的答案 [1][2][3] 支持我的想法，即直接绑定到模型真的没问题。

【问题讨论】：

标签： c# mvvm observablecollection

【解决方案1】：

这一切都归结为代码分离和可重用性。理想情况下，视图应该与模型完全分离。如果 View 不依赖于 Model 的特定实现，那么它可以与不同的模型重用以呈现一些其他数据。

所以，假设您有一个AlbumView，并且您当前的模型是Album，但将来您决定将Movie 或Book 添加到您的库中。您仍然可以使用相同的AlbumViewo 显示您的电影和书籍对象。此外，如果你想创建一个与专辑有关的新项目，你可以简单地重用你的 Album 类，因为它不依赖于任何视图。这就是 MVVM 或 MVC 的优势。

所以对我来说，我想说，你的同事是对的，因为模型自然地反映了数据访问层实体，它将被存储和处理。除此之外，Model 可能还有更多与 Access 数据层相关的属性，例如createdindexing。而您ViewModel 仅与应用程序的视图和表示逻辑有关。它只反映用户将要看到的内容。

【讨论】：

“此外，如果你想创建一个与专辑有关的新项目，你可以简单地重用你的 Album 类，因为它不依赖于任何视图。”但两者都是如此我们的方法。我还认为 MVVM 的重点是模型的可重用性，而不是视图的可重用性。我一直认为“不同的模型 -> 不同的视图；不同的视图 -> 相同的模型”。

【解决方案2】：

我会说在Model 层中使用ObservableCollection 是错误的。通过添加，您基本上是在说“Model 对象存储数据并在更改时通知”。

ViewModel 的作用是操作Model 并为View 提供接口以呈现Model。

我相信你的同事是对的，因为他正在强制执行关注点分离，以便操纵 Model 不会影响 View。

【讨论】：

“通过添加，您基本上是在说“模型对象存储数据并在它更改时通知”。但不知何故，您必须将更改通知某人（视图或视图模型）。
不，应该通过 ViewModel 进行更改。
但是为什么ViewModel要知道Model的内部业务逻辑呢？
我不同意。 ViewModel 不需要知道 Model 如何获取其数据，无论是通过数据库、XML 文件还是其他方式。如果我的数据库中的某些数据发生更改，更改应该直接转到 Model，而不是先通过 ViewModel。
确实如此。如果我们谈论的是 UI 呈现模式，MVVM（我们就是），那么所有更改都必须从 View 到 VM 再到 Model。 VM 层可能会响应来自其他进程协调器的一些其他输入，但是让一个愚蠢的模型/DAL 实体实现通知是破坏模式。在 MVVM 中谈论“模型”和谈论单个模型实体是有区别的。