C# 实体与模型与视图模型

我只是花了一些时间阅读了这些术语（我不太使用它们，因为我们没有任何MVC应用程序，我通常只说“模型”），但我感觉这些术语根据上下文的不同有不同的含义：

实体

这很简单，它是数据库中的一行：

2） 就数据库而言，实体是单个人、地点或实体 关于哪些数据可以存储的事情

型号

我经常读到，这基本上是实体的组合来表示一整套数据，比如说，客户的地址列表模型将结合实体客户、地址，可能还有个人

视图模型

MVVM或MVC模式中的一个术语，它是一个模型，精确地表示您可以在视图上看到的数据。viewmodel位于应用层上，并具有用于验证的属性f.e

在我看来，这些术语似乎都有点多余：Viewmodel显然有他的用途，否则视图将不得不做所有艰苦的工作来显示正确的内容。实体只是表示，正如我们从EF中了解到的，但是如果你将这两者结合起来，那么模型在哪里使用呢

验证、安全性等工作必须在ViewModel上完成。当您有数百个小表在实体和viewmodel之间放置另一个抽象时，您会使用该模型吗？或者MVC和MVVM的实体和模型通常是相同的

像往常一样，谢谢，祝你周末愉快

---

Matthias

不同的人对这些术语的理解有点不同，但我就是这样理解的：

实体-具有标识（ID）的对象，通常来自数据库。相当简单的类

模型-任何业务对象，这是一个广义的术语。它可以是一个实体，也可以是您在项目中创建的某个自定义类等。。几乎所有东西都不是视图，也不是控制器/视图模型

---

ViewModel—模型和视图之间的某种中介。它调节模型和视图之间的通信，例如应用验证，将更多模型组合成一个更大的对象等，以便与特定视图交互。ViewModel还负责事件处理（例如，单击鼠标按钮），因此它向绑定到的视图（WPF）公开命令。

我的理解是，模型是这里的核心概念，它反映了对正在解决的问题的理解。这些实体决定了模型对象将如何存储在数据库中。Viewmodels确定模型的哪个部分将显示给最终用户。

术语“模型”不明确。他们都是模特

实体模型 在持久性方面与结构非常相似的类。MemberEntity是表示数据库中Members表中一个成员行的模型。不是严格地绑定到数据库，而是某种持久性的实体。通常具有“ID”属性，如“int MemberID”

视图模型 与视图/UI上的结构非常相似的类。MemberViewModel是一个模型，表示一个成员将显示在应用程序前端的成员视图/UI上。与MV*模式没有严格的联系

通知 …以上两个模型表示应用程序边界上的通信。即，接收通信（用户事件和通过协议的通信）以启动业务规则的前端边界（入口点）；以及后边界，它从业务规则获取命令，以打开与其他系统（如数据库或其他端点）的通信

域模型 表示问题域的一部分的类。成员模型负责其创建和验证。因为服务接收和返回模型，所以模型负责它们自己的业务逻辑，从而验证它们的正确构造和使用。例如：如果您尝试在没有用户名的情况下使用MemberModel，则它应该会中断

域服务 域服务采用实体模型，并将其转换为域模型，以便所述服务可以与模型一起工作。如果一个实体从后边界进入，并且未能序列化或映射到域模型中，则会发出一个红旗，表明数据不正确

域服务采用域模型并将它们映射到实体，以便将它们发送到后边界。如果后边界（DB/SDK？）无法接受模型，则需要修复DB/SDK

• 注意：实体符合模型，因为持久性是一个细节。域是系统之王，而不是持久性的硬件或表结构。这个领域从来没有错

前边界获取视图模型，并将其转换为域模型，以便将其传递到域中。如果ViewModel未能序列化或映射到域模型，则会出现一个红色标志，表明view/json/xml不正确

域服务将域模型返回到前端边界，然后映射到视图模型，以便在前端进行通信。如果视图/UI无法接受模型，则需要修复视图

• 注意：视图模型符合模型，因为消费者是一个细节。域是系统之王，而不是用户界面或使用它们的子应用程序。这个领域从来没有错

视图模型永远不知道实体的存在，因为UI/使用者永远不知道持久性的存在

核心业务逻辑不应了解ViewModels或实体。核心业务逻辑仅适用于域模型。这就是为什么控制器和它们附近的前端服务存在的原因；映射域模型视图模型。这也是为什么