严格分离视图和模型的好处是什么？
严格分离视图和模型的好处是什么？
我的一个同事不想直接从视图(View)绑定到模型(Model)。例如，在模型中，他有一个ObservableCollection，而在视图中，他想使用它。他不像我直接使用它那样（例如，{Binding Model.Collection}），而是在ViewModel中有另一个ObservableCollection，它与模型中的ObservableCollection具有完全相同的数据。他通过事件将这两个ObservableCollections彼此同步。\n他的方法有什么好处？就我个人而言，我不赞同他的方法，因为它只是增加了重复的代码，并且由于你必须自己同步ObservableCollections，所以容易出错。我的同事说他想这样做是因为这样他可以在不改变视图的情况下改变模型。\n编辑：\n一些得到高票支持的答案（1）（2）（3）支持我的想法，即直接绑定到模型是可以的。
严格分离视图和模型的好处是什么？
在这段对话中，讨论了在模型层中使用ObservableCollection是否合适的问题。其中，提到了以下一些观点和问题：
1. 使用ObservableCollection会让模型对象存储数据并在数据发生变化时通知其他对象。但是，为什么要让模型对象通知其他对象，而不是由其他对象来通知模型对象呢？
2. 视图模型应该知道模型的内部业务逻辑吗？
3. 视图模型是否需要知道模型从何处获取数据？
4. 在MVVM（Model-View-ViewModel）模式中，所有的变化都应该从视图（View）传递给视图模型（ViewModel），然后再传递给模型（Model）。在MVVM模式中，模型对象不应该实现通知功能。
5. 对于MVVM模式中的个体模型实体和整个模型的讨论，有一些区别。
根据以上讨论，可以总结出严格分离视图和模型的好处是为了实现模块化、降低耦合性和提高代码可维护性。为了解决以上问题，可以采取以下解决方法：
1. 在MVVM模式中，使用视图模型来处理与视图的交互，而不是直接在模型中处理。
2. 视图模型不应该直接知道模型的内部业务逻辑，而应该通过与模型进行数据交互来完成视图的更新。
3. 视图模型不需要了解模型从何处获取数据，而是通过模型来获取数据并将其传递给视图。
4. 在MVVM模式中，模型应该尽量保持简单，只负责存储数据，而不应该实现通知功能。
5. 通过严格分离视图和模型，可以使代码更加清晰、易于理解和维护。
严格分离视图和模型的好处是为了实现模块化、降低耦合性和提高代码可维护性。在MVVM模式中，视图模型负责处理与视图的交互，而模型只负责存储数据。通过遵循这种分离原则，可以使代码更加清晰、易于理解和维护。
严格分离视图和模型的好处是代码分离性和可重用性。理想情况下，视图应该与模型完全分离。如果视图不依赖于特定的模型实现，那么可以重用它来呈现其他数据的不同模型。
假设你有一个AlbumView，并且你当前的模型是Album，但未来你决定还要将Movie或Book添加到你的库中。你仍然可以使用相同的AlbumView来显示电影和图书对象。此外，如果你想创建一个与专辑有关的新项目，你可以简单地重用Album类，因为它不依赖于任何视图。这就是MVVM或MVC的优势所在。
所以对我来说，我会说你的同事是对的，因为模型自然反映了数据访问层实体，它将被存储和处理。此外，模型可能有更多与访问数据层相关的属性，例如创建时间和索引。而ViewModel只与视图和应用程序的展示逻辑相关。它只反映用户将要看到的内容。
"此外，如果您想创建一个与专辑有关的新项目，您可以简单地重用Album类，因为它不依赖于任何视图。"但是这在我们两种方法中都是适用的。我还以为MVVM的重点是模型的可重用性，而不是视图的可重用性。我一直认为“不同的模型->不同的视图；不同的视图->相同的模型”。