我认为我没有正确理解 MVVM 模式，因为拥有 Model 和 ViewModel 类对我来说似乎是多余的。
我对 Model 的理解基本上是在一个类的小细节中添加一些细节，让 ViewModel 处理所有的逻辑和实现。如果是这样，为什么要把两者分开？你不能在视图模型中创建变量、属性等并且仍然有逻辑吗？
对我来说，在某种程度上它听起来像 C++。你有描述类的头文件和定义类的实现文件。在c#中这样做有什么意义吗？
我觉得我不理解分离，因为我不完全理解 MVVM 模式。如果有人可以为我澄清它，那就太棒了。
提前致谢。
【问题讨论】：
标签： c# wpf design-patterns mvvm viewmodel
为了让这个答案更具体，让我们看一个例子。您想在一个漂亮的 WPF 程序中使用相同的旧“计算器”示例。
您不必在视图模型中跳入并编写所有内容，而是记得您实际上是在很久以前为另一个项目编写的，并且您实际上足够聪明，可以将所有计算器功能都放在一个单独的（且可重用的）dll 中。
所以，你得到了你的模型。
现在剩下的就是您的 GUI。您在 WPF (View) 中绘制了一个漂亮的闪亮窗口，然后您需要将调用和数据从 dll 桥接到视图。你猜对了……这是你的 ViewModel :)。
另一方面，我们的想法是能够在一个大团队中工作，其中一些人负责逻辑（模型），一些设计师负责视图，而其他人（当然可以是上述任何人）可以让这些位与视图模型一起工作。
【讨论】：
模型代表您的数据。 viewmodel 只使用这些模型来驱动你的 UI。模型应该代表实体……事物。 Viewmodels 使用这些东西，这就是区别。
【讨论】：
问题在于用户界面本身可能变得相当复杂。你到处都有小部件——滑块、文本字段、按钮、复选框、单选按钮——有时视图不仅仅是“用模型中的这些值填充这些空白”。从 UI 的角度来看，ViewModel 是您的数据模型。通常这是对完整视图的简化，但也可能是复杂的（例如，如果您有一个由多个控件构建的聚合字段，这些控件存储在持久存储中的单个属性中）。
【讨论】：
一个更简单的例子。在当前的分布式架构中，您的数据库（模型）和业务逻辑（VM）没有必要设计在同一个物理系统上。因此，数据（模型）可能会被某些服务（如 WCF 或 WebApi）公开，然后 VM 可以轻松使用这些服务（通过在项目中添加相应的 dll）。
更重要的一点是，您不必在 UI 上显示数据库中表格的每一列。因此，通过拥有一个模型，VM 只会在 UI 上获得最终用户所需的相关数据。
【讨论】：