MVVM——模型的正确实现答案

【问题标题】：MVVM – Correct implementation of the ModelMVVM——模型的正确实现
【发布时间】：2015-05-06 21:09:41
【问题描述】：

背景：
C#/WPF Windows-Store 应用程序使用 SQLite 在本地存储数据，并通过 Web 访问下载数据。

应用：
数据必须从 Web 下载并映射到存储在本地 SQLite 数据库中的类。例如，在 Customer 类中：

[Table("Customer")]
class Customer{
    [AutoIncrement, PrimaryKey, Unique]
    public int Id {get;set;} 
    public string Name {get; set;}
    …
}

该类由不同的线程操作，因此 Customer 类中的 INotifypropertyChanged 是个坏主意。此外，GUI 应该显示多个客户，因此 ViewModel 包含客户列表。此外，必须通过几个属性扩展客户才能由 GUI 正确显示。

问题：
型号是什么？客户？
我应该如何使用其他属性扩展客户而不弄乱客户类？
除了将客户存储在数据库中或从网络下载数据并将其映射到客户类的业务逻辑之外，我应该在哪里？在模型中？
如果你的答案是 Customer 是 Model 并且它不应该包含任何逻辑，为什么 MVVM 模式说 Model 包含业务逻辑？

【问题讨论】：

标签： c# mvvm

【解决方案1】：

在这种情况下，客户肯定是模型。模型应该是POCO，并且每个仅由 GUI 使用的属性都应该在视图模型中，例如 CustomerViewModel。

业务逻辑应该在模型中。使用repository pattern可以解决存储在数据库中的问题。

模型通常具有逻辑，但仅限于业务逻辑。根据 MVVM，您不应将任何 UI 逻辑放在模型中，而应放在视图模型中。

假设我们有你的模型

class Customer {
    public int Id { get; set; } 
    public string Name { get; set; }
}

并且需要以大写形式显示客户姓名。与其向 Customer 类添加其他属性，不如在视图模型中添加一个

class CustomerViewModel implements INotifyPropertyChanged  {
    ...
    public string UpperCaseName { ... }
    ...
}

我认为Wikipedia page 总结得很好：

型号

模型指的是表示真实状态内容的域模型（一种面向对象的方法），或者指数据访问表示该内容的层（以数据为中心的方法）。

查看

在 MVC 和 MVP 模式中，视图是用户界面 (UI)。

查看模型

视图模型是公开公共属性和命令的视图的抽象。而不是 MVC 模式的控制器，或者说MVP模式的presenter，MVVM有一个binder。在视图中模型，这个绑定器调解视图和视图之间的通信数据粘合剂。视图模型已被描述作为模型中数据的状态。

活页夹

声明性数据和命令绑定隐含在 MVVM 模式中。在 Microsoft 解决方案堆栈中，活页夹是一种标记称为 XAML 的语言。活页夹使开发人员免于被必须编写样板逻辑来同步视图模型和看法。在 Microsoft 堆栈之外实施时，存在声明式数据绑定技术是该模式的关键推动力。

【讨论】：

【解决方案2】：

什么是模型？

拥有 / 的实体或任何类是数据的框架。

我应该如何在不弄乱 Customer 类的情况下使用其他属性扩展 Customer？

通过Partial 类修饰符。允许您将专门的逻辑放入扩展操作/属性中。另外，您可以让客户坚持 INotifyProperty 更改。

除了将客户存储在数据库中或从网络下载数据并将其映射到客户类的业务逻辑之外，我应该在哪里？在模型中？

把所有的业务逻辑都放在ViewModel中获取和存储信息。这是魔法发生的地方，是View 和Models 之间的管道，供View 显示。

为什么 MVVM 模式说模型包含业务逻辑？

业务逻辑以构成数据的实体的形式出现。

刚接触 MVVM 的人总是想知道他们是否正确地遵循了 MVVM。 MVVM（恕我直言）只是一个三层数据系统（记住那个范式），它将数据与逻辑分离以获取数据以最终显示数据；三层。

如果将 MVVM 视为老式的三层数据系统，其中 VM 包含/获取数据（称为模型）并处理业务逻辑以处理数据，并简单地允许视图显示所述数据；就是这么简单。

【讨论】：