一些MVVM问题（WPF C#）

我最近一直在研究MVVM，我似乎已经了解了总体思路。有几点我不太明白，我想在这里得到一些答案，干杯

对整个应用程序使用一个数据模型是否不正确。通常，如果我创建一个小实用程序，我会将所有逻辑数据放在一个类中。这意味着我可以有如下内容：

DataStore myData = new DataStore;

`DataStore myData = new DataStore; `

如果可以有一个数据模型，那么可以有多个模型视图，比如一个表示每个窗口或视图（这就是我设想的MVVM工作方式）

如上所述，如果有多个模型视图，那么似乎必须在第一个窗口（视图）之前声明模型，应该在哪里声明？是否应通过对后续模型视图的引用来传递模型？这不是耦合的来源，因为窗口或页面（视图）需要了解模型才能将其传递到其模型视图，因为视图实例化了模型视图

抱歉，如果这是一个很多问题，我在一个窗口或页面的意义上得到了MVVM的想法，但一旦我添加了多个视图，我的系统就崩溃了。我可以让它与访问外部源的独立模型一起工作以获取其数据，但是如果数据需要在视图之间保持，我就会丢失

感谢所有花时间回应的人

一些想法：

简单的应用程序不一定需要MVVM的复杂性——您可以省去ViewModel，直接使用底层模型。只是要小心不要将这种方法延伸到临界点——因为WPF非常依赖于INotifyPropertyChanged和DependencyProperties之类的东西。您不希望不必要地开始将它们合并到模型类中

是的，没关系。但是，…请记住，如果只有一个模型实例，则更简单，否则在保存时需要合并来自多个视图的更改（或丢失一个版本的更改）。如果ViewModels引用相同的基础模型，则这是可行的

您无法避免MVVM中的某种程度的耦合。但是，（如果我正确理解您的问题的话）在模型视图之间引入耦合可能是个坏主意，因为它破坏了使每个视图成为模型上为特定视图优化的离散透视图的目的

我自己的经验：

我不认为在整个应用程序中使用一个数据模型有什么错，这取决于您想要做什么。只要将其与视图分开，您就处于MVVM设计模式中

我个人喜欢为我的每个视图使用ModelView。我认为有不同的观点，但我个人认为，通过这样做，一切都保持了模块化和单元可测试性

我试图避免模型视图之间的耦合。如果我的每个视图都有一个模型视图，我会在每个视图中分别声明每个模型视图。然后通过事件将每个视图实例化到主视图中。这将使用MVVM模式，您可以分别对每个模型视图进行单元测试

如果你已经读过这篇文章，我不会感到惊讶，但是对于那些想了解MVVM设计的人来说，这里有一个很好的例子

使用一个数据是否不正确 整个应用程序的模型。 通常，如果我正在创建一个小的 实用程序我将拥有所有的 一个类中的逻辑数据。这 意味着我可以拥有像 以下:

DataStore myData = new DataStore;

`DataStore myData = new DataStore; `

这很好。您的数据模型就是您的数据模型，应该以尽可能最好的方式表示数据，无论是在一个类中还是在1000个类中

如果可以使用一个数据模型 有多个型号可以吗 视图，例如一个代表每个视图 窗口或视图（这是我 设想MVVM工作）

当然，在我看来，这正是你应该做的。一般来说，无论视图是控件还是窗口，每个视图都需要一个视图模型。在某些情况下，您可能会发现为一个特定视图使用多个视图模型会有所帮助，但我会首先查看以确保我没有一个应拆分的视图

如果一个有多个 模型视图看起来 模型必须在之前声明 第一个窗口（视图），应该在哪里显示 应该申报吗？模型应该是 通过对后续文件的引用传递 模型视图？这难道不是一个好消息吗 耦合源作为窗口或 页面（视图）需要了解 要将其传递到其模型视图的模型 因为视图实例化了模型 视图

---

现在你进入了宗教领域。我将对此稍作说明，并说做对您的应用程序有意义的事情。也就是说，如果您想减少模型和视图/视图模型之间的耦合，我强烈建议您从模型类中提取接口。在App.xaml.cs文件中创建模型，然后将其传递给视图（model）将非常简单作为接口的实现。

绝对同意：数据绑定体系结构的好处之一是，您可以在简化的模型-视图体系结构中工作，并且只有在视图开始要求时，才可以扩展到更复杂的MVVM方法。为了支持更简单的体系结构，我会毫不犹豫地在模型类上实现INotifyPropertyChanged（尽管我同意一旦您开始需要推出DPs，您可能就进入了视图模型领域）。是的，您理解正确。我知道我可以缩短流程，但我正在尝试（令人沮丧的是，我可能会补充）在使用更大的应用程序之前学习MVVM。看来我的工作很忙