实体与模型与视图模型
我只是花了一些时间阅读这些术语（我没有那么多使用它们，因为我们没有任何MVC应用程序，我通常只是说“模型”），但我觉得这些意味着不同的东西取决于上下文：
实体
这很简单，它是数据库中的一行：
2）关于数据库，实体是可以存储数据的单个人，地点或事物。
模型
我经常读到，这基本上是实体的组合以表示一整套数据，假设客户的地址列表模型将实体客户，地址和可能的个体组合在一起。
视图模型
MVVM或MVC模式中的一个术语，它是一个模型，它完全代表您可以在视图上看到的数据。 viewmodel位于应用程序层，具有validation属性，即ASP.NET MVC Model vs ViewModel
从我的视线来看，这些术语似乎有点多余：Viewmodel显然已经使用了它，否则视图将不得不做所有努力来展示正确的东西。 正如我们从EF中所知，实体只是表示，但如果你将这两者结合起来，那么模型的使用在哪里？
必须在ViewModel上完成validation，安全等操作。 当你有数百个小表在实体和viewmodel之间放置另一个抽象时，你会使用该模型吗？ 或者在MVC和MVVM实体和模型方面通常是一样的吗？
像往常一样感谢周末愉快
马蒂亚斯
不同的人对这些术语的理解有点不同，但这就是我理解它的方式：
实体 – 具有标识（ID）的对象，通常来自数据库。 非常简单的课程。
模型 – 任何业务对象，这是一个有点广泛的术语。 它可以是一个实体，一些你在项目中创建的自定义类等。它几乎都是视图，也不是控制器/视图模型。
ViewModel – 模型和视图之间的某种中介。 它调制模型和视图之间的通信，例如应用validation，将更多模型组合成一个更大的对象等，以便与特定视图交互。 ViewModel还负责事件处理（例如按钮鼠标点击），因此它将命令公开给您绑定到的视图（WPF）。
术语“模型”含糊不清。 他们都是模特。
实体模型
一类与持久性结构非常相似的类。 MemberEntity是一个模型，它表示数据库中Members表中的一个成员行。 不是严格依赖数据库，而是某些持久性的实体。 通常具有“ID”属性，例如“int MemberID”。
视图模型
一个类似于View / UI上的结构的类。 MemberViewModel是一个模型，它表示要在应用程序前端的成员视图/ UI上显示的一个成员。 不严格依赖于MV *模式。
注意
……上述两个模型代表了应用程序边界的通信。 也就是说，接收通信（用户事件和通过协议的通信）以发起业务规则的前边界（入口点）; 并且后边界从业务规则获取命令以打开与其他系统（例如数据库或其他端点）的通信。
领域模型
表示问题域的一部分的类。 MemberModel负责其创建和validation。 由于服务接收和退出模型，模型负责自己的业务逻辑，validation其正确的构造和使用。 EG：如果您尝试在没有UserName的情况下使用它，则MemberModel应该中断。
域名服务
域服务采用实体模型并将它们转换为域模型，因此所述服务可以与模型一起使用。 如果实体从后边界进入并且无法序列化或映射到域模型，则存在数据不良的红色标记。
域服务采用域模型并将它们映射到实体 ，以便将它们发送到后边界。 如果后边界（DB / SDK？）无法接受模型，则需要修复DB / SDK。
- 注意：实体符合模型，因为持久性是一个细节。 域是系统之王，而不是持久性的硬件或表结构。 域永远不会错。
Front-Boundaries采用ViewModels并将它们转换为Domain Models，以便将它们传递到Domain中。 如果ViewModel无法序列化或映射到域模型，则会出现一个红色标记，表明view / json / xml不正确。
域服务将域模型返回到前边界，然后将其映射到ViewModels以便在前面进行通信。 如果View / UI无法接受模型，则需要修复View。
- 注意：ViewModels符合模型，因为消费者是一个细节。 域是系统的王者，而不是消费它们的UI或Sub-Apps。 域永远不会错。
ViewModel永远不会知道实体，因为UI / Consumer永远不会知道持久性甚至存在。
核心业务逻辑不应该了解ViewModel或实体。 核心业务逻辑仅适用于域模型。 这就是控制器和它们附近的前端服务存在的原因; 映射域模型<=> ViewModels。 这就是为什么SDK和它们附近的后端服务存在的原因; 映射DomainModels <=>实体。
构建系统时，首先构建域和业务逻辑（希望是TDD）。 然后将适配器放在业务逻辑的正面和背面，它确定传递机制（前端）和依赖（服务/持久性）（后端）。 但是这些前端和后端可能会被淘汰，核心业务逻辑仍然存在。
更短版本（TLDR;）：
实体：数据库记录。
域模型：特定于模型的业务逻辑（Google“值对象”），用于表示域问题中的对象。
ViewModel：视图的页面（或部分）。
我的理解是模型是这里的核心概念，它反映了对正在解决的问题的理解。 实体确定Model对象将如何存储在数据库中。 Viewmodels确定将向最终用户显示Model的哪个部分。
这些术语的定义非常模糊。 您会在不同的地方找到不同的定义。
实体 ：实体表示域对象的单个实例作为记录保存到数据库中。 它有一些我们在表中表示为列的属性。
模型 ：模型通常表示与问题或域空间相关的现实世界对象。 在编程中，我们创建表示对象的类。 这些类称为模型，具有一些属性和方法（定义对象行为）。
ViewModel ：术语ViewModel源自MVVM （模型视图ViewModel）设计模式。 在某些情况下，视图要呈现的数据来自两个不同的对象。 在这种情况下，我们创建一个模型类，它包含视图所需的所有属性。 它不是域模型而是ViewModel，因为特定视图使用它。 此外，它不代表现实世界的对象。
有关更多详细信息，请访问： 实体与模型对比ViewModel与DataModel
不同的人以不同的方式定义实体，模型和ViewModel。 然而，基于上下文，这些术语有时可能与其实际含义不同。
实体
实体是数据库中域类/对象的表格表示，并具有标识。 实际上，实体表示域对象的单个实例作为记录保存到数据库中。 它有一些我们在表中表示为列的属性。
例如，为了将Customer表示为实体，它必须具有一些属性，如CustomerId，CustomerName，Address等等，具体取决于上下文。 因此，这些属性构成了Customer表的列。 因此，您在表中保存的每个客户数据代表一个客户实体。
模型
人们常常将实体与模型混为一谈。 但是，这两者完全不同。 模型通常表示与问题或域空间相关的现实世界对象。 编程时，我们创建表示它们的类。 这些类（称为模型）在特定域空间中具有一些属性和方法（定义其行为）。 例如，在任何面向客户的问题中，我们可能有一个具有一些属性和方法的客户类。
在一些ORM（对象关系映射器）框架中，模型与实体紧密绑定。 这意味着每个标量属性都映射到实体属性。 但是，如果您熟悉Entity Framework，则必须知道，并非域类中的所有属性都映射到实体列。 这是实体与模型不同的一种方式。
视图模型
术语ViewModel源自MVVM设计模式。 在MVVM设计模式中，viewmodel包含处理视图生成的请求/事件的所有逻辑。 我们可以说MVVM模式中的视图模型就像MVC模式中的控制器。
但是，还有一个方面。 视图负责呈现通常来自对象的数据。 但是，有些情况下，数据来自两个不同的对象。 在这种情况下，我们创建一个模型类，它包含视图所需的所有属性。 然后，不同的域模型实例初始化此对象。 它不是域模型而是视图模型，因为特定视图使用它。 此外，它不代表现实世界的对象。