MVVM在ViewModel中复制模型属性

似乎有一个指导原则，即模型不应将其实体公开给视图，所有必需的属性都应在ViewModel中复制

例如：

Product
Id {get; set;}
Name {get; set;}
.......


ProductViewModel : ViewModelBase
Id {get; set;}
Name {get; set;}
.......

---

为什么需要这样做？如果模型没有实现INPC，我可以理解这一点，但如果它实现了，那么我觉得这是非常不必要的。

指南，就是这样。这取决于手头的情况。纯粹主义者会争辩说，将模型与视图完全分离允许模型在不改变视图的情况下改变

如果有必要，我倾向于只代理模型属性（INPC或某些视图特定的逻辑，如模型有FirstName和LastName，但没有全名）

否则，我将绑定到模型（它是ViewModel上的公共属性）。如果我的情况发生了变化，我需要封装一些东西，那么当我有需要的时候我就会重构

---

我总是试图确保有一个ViewModel（即使它只公开模型），这样以后重构就更容易了。

我的问题是，为什么您的模型要实现INPC？他们需要吗

通常模型只是一个DTO，不需要任何更改逻辑

此外，如果您的INPC基本实现来自MVVM框架，但您的模型存在于共享程序集中，那么该程序集是否需要对您的MVVM框架以及其他WPF程序集的引用

---

我们的场景是一组共享对象，表示服务器端和客户端上的数据。客户端是一个WPF应用程序，所以这很好，但服务器端是一个服务，所以我们不需要INPC。

当视图绑定到模型时：

• 如果视图需要更改，或者您有多个视图，对模型的更改将导致绑定到该模型的所有视图的更改

• 从视图的角度来看，它绑定到的对象可能没有那么直观；当需要向对象添加特性和/或命令时，是将这些特性和/或命令添加到ViewModel并在模型中保留“原始”特性，还是修改模型

拥有ViewModel可以在单个模型和多个（版本）视图之间提供额外的抽象

---

总而言之，这只是一个指导原则，但请注意，当您需要修改/更新应用程序时，今天看起来不错的可能并不太好。

您的ViewModel不正确。 如果您已经有了产品类型的模型，您可以在ViewModel中简单地定义如下内容：

---

公共产品产品{…}

我认为模型是由外部源（代理类、存储库、流）提供的任何东西，只有当我想通过绑定到它的更改来更新视图时才需要。我从来没有将模型绑定到视图，原因在我的回答中，这就是ViewModel的用途。嗨，Erno，很抱歉响应太晚，我在度假。你的第一点很强。第二点的答案是：是的。如果我可以这样问：如果您需要有关customer的简短信息，例如仅代码、名称和Id，您是否会有一个CustomerBasicInfoViewModel，它只包含这三个属性，使用完整的customer对象作为DTO（包含所有属性），或者您也会在模型中包含CustomerBasicInfo，以保留内存？一如既往：这取决于。在WPF（一个桌面应用程序）中，我不会担心几（千）字节的内存，但我会首先担心带宽。大多数情况下，带宽决定了物体的大小。嗨，卡梅隆，很抱歉反应太晚，我在度假。嗯，必须有人实现INPC，即客户（模型）或客户服务模型。我们是否在每个场景中都需要DTO？若您想从模型中引入对MVVM框架的引用，可以，但不是必需的。INPC的实现非常简单。MVVM框架中的ViewModelBase仍将用作VIewModels的基础。我的问题是：如果我问一个问题“我是否应该复制VM中的所有模型属性”，答案是肯定的，无论应用程序类型如何，我都想知道-为什么？嗨，Adam，很抱歉我的回答太晚了，我在度假。那么，您如何处理需要在发票视图上显示客户集合的情况，其中只需要非常基本的信息（示例代码、名称和Id）。您的模型中是否有CustomerBasicInfo，或者…？通常，模型由您的域、Web服务等指定给您。因此，您可以创建一个viewmodel来包装模型，并使视图更容易显示数据（例如，添加属性，如selected、visible等）。如果您有一个只读视图，并且您的模型与视图结构非常相似，那么您可以随时立即使用它，并在以后随着等级库的更改将其替换为viewmodel。小心让UI问题潜入你的模型，这是他的问题的核心！将模型公开给视图会绕过ViewModel的责任。