在 WPF 中使用模型有什么意义

本文关键字：什么 模型 WPF | 更新日期: 2023-09-27 18:03:23

到目前为止，我还没有看到在WPF中使用模型的价值。按照惯例，我所有的视图模型都有一个关联的模型。这些模型中的每一个都是其各自视图模型的虚拟克隆。ViewModel 和 Model 类都实现了INotifyPropertyChanged，而 ViewModel 只是将所有内容委托给模型。

那为什么要费心拥有模型呢？为什么我不能将我的模型逻辑移到 ViewModel 中并调用它一天？

拥有 MVVM 似乎相当多余(即不是 DRY(，默认情况下只使用 VVM，除非某些特殊的边缘情况需要模型。

例如，如果使用显式模型类更好地支持单元测试或其他一些最佳实践，我可以看到其价值。

在 WPF 中使用模型有什么意义

该模型只是低级应用程序数据。

视图模型更具体。

  • 它就像一个窗口，点击为视图量身定制的数据。
  • 它还使用视图所需的详细信息来扩充模型。一个很好的例子是分页。
  • 一个模型可以有多个视图模型。这些视图模型将提供数据的不同方面。
  • 您可以创建不同数据源的混搭。视图模型可以清晰地显示所涉及的模型。

这意味着模型和视图模型之间没有 1：1 的关系。

因此，如果您只显示低级数据而不显示大量额外的逻辑、功能、摘要、聚合、过滤器等，则可以取消视图模型，而直接使用该模型。您的项目似乎就是这种情况。

模型可以自动生成(实体框架(，也可能根本不是特定类(想想数据表(。

我假设如果你说"我不使用模型"，你实际上确实使用了一个模型，你只是不这样称呼它。

首先，即使在 MVVM 中，您也可以直接在 VM 中公开模型，并通过它绑定到模型。 {Binding MyModel.MyModelsProperty}这样DataContext = ViewModel，您不必包装所有内容，除非这只是您的风格。

视图模型和模型具有不同的职责。例如，考虑设计具有文件夹树视图的文件资源管理器。树视图中的每个节点都是一个目录/文件夹。目录是模型，它们具有与文件系统相关的属性。ViewModel 可以包装或公开这些属性以供 TreeView 节点显示(例如目录的名称(，但它也会添加其他信息(如"IsEdit"和"IsExpanded"(来确定节点所处的状态。

你只是在谈论 MVVM 中的一个模式，实际上还有更多。

在有状态视图模型中，您实际上不会将事情委托给模型，Viewmodel 本身会保持其状态，因此正如您在此模式中所说，您几乎可以忽略模型，因为您可以在 VM 本身中拥有状态。

在业务逻辑和表示、数据之间创建隔离 应从视图中删除。有状态视图模型模式移动 数据使用 XAML 数据绑定到视图模型中。这允许视图 在不构造视图的情况下测试模型，它允许视图 以对业务逻辑的影响最小地进行更改。

在无状态视图模型中，您将调用委托给模型，这可能是您所指的。

请注意，您不一定在 Model 中实现INotifyPropertyChanged。只要不直接在模型中更改属性，只需在 VM 中实现它就可以了。

那么为什么我们需要虚拟机和模型呢？VM用于支持视图，例如提供命令等，而模型只是为了保持数据抽象相同。

如果您将其视为抽象，假设您需要构建一个屏幕来显示员工列表并进行选择、搜索或过滤。然后我们将其分解为组件。您将需要：

  1. Employee类(模型(
    2. EmployeeManagementViewModel，用于
  2. 准备和显示您的员工列表并管理您的视图的状态更改(例如，可以包含SelectedEmployee、过滤器搜索文本等(，以供您的EmployeeManagementView
    3. 使用
  3. 员工名单(将存在于您的EmployeeManagementViewModel中(

很可能你已经有Employee课了。如果是这种情况，那么您只需要在EmployeeManagementViewModel中将该模型作为员工ObservableCollection公开即可。

如果您还没有 Employee 类，您可以决定创建一个EmployeeViewModel并在那里添加您的Employee属性，如 FirstName、LastName 等。

从

技术上讲，这将起作用，但从概念上讲，它困扰着我，因为EmployeeViewModel不是员工(它包含员工(。如果要抽象现实，则员工的蓝图不应包含视图要使用的属性或方法。对我来说，员工应该是一个可以实施INotifyPropertyChanged的 POCO，仅此而已。您将视图状态与模型本身分开。拥有员工 POCO 可以更轻松地进行单元测试、创建模拟员工、通过 ORM 将其映射到数据库表等。

顾名思义，视图模型是视图的模型，模型是业务领域的模型

无论如何，我就是这样看的。当我开始做MVVM工作时，我有同样的问题，但多年来似乎这是有道理的。

通常，我的模型最终会成为数据访问层，无论是通过实体框架、WCF 代理还是其他类。

根据并发问题，该类可以是静态的，也可以是实例化的。如果可以充分分离行为，则可以将 DAL 类"拆分"为每个视图模型的单独模型中，但重复的代码可能会成为问题。

维基百科：MVVM

模型：与经典的 MVC 模式一样，模型是指 (a( 表示真实状态内容的域模型(面向对象的方法(，或 (b( 表示该内容的数据访问层(以数据为中心的方法(。

您的ViewModel不能替代您的域名Model。它充当视图和模型之间的中间体，包括命令、将集合绑定到视图、验证等。

您的域模型也应该可跨ViewModels重用。如果在 VM 中实现所有内容，则最终会滥用 DRY 原则，在多个 VM 之间共享特定的 VM 逻辑。

根据我的经验，当您仅使用域模型作为 ViewModel(作为 VM 的属性(时，您最终会得到很多键，这些键要求您获取文本值并存储在其他地方，或者您最终还是将属性添加到 VM。 您的视图通常包含比单个域模型(例如相关对象、显示值、文本状态值等(更多的信息，域模型不需要这些信息，最终会加重它。 视图模型专用于视图的需求，它不断对视图进行简单和非复杂的编码。

相关文章：