实体与模型与视图模型[重复]

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

Entity

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

2. 就数据库而言，实体是单个人、地点或 关于可以存储哪些数据的问题。

Model

我经常读到，这基本上是表示完整数据集的实体组合，假设客户的地址列表模型将组合实体客户、地址和可能的个人。

视图模型

MVVM 或 MVC 模式中的一个术语，它是一个模型，它准确地表示您可以在视图上看到的数据。视图模型位于应用程序层并具有用于验证的属性，例如ASP.NET MVC 模型与 ViewModel https://stackoverflow.com/questions/4061440/asp-net-mvc-model-vs-viewmodel

在我看来，这些术语似乎有点多余：Viewmodel 显然有他的用处，否则视图将不得不做所有艰苦的工作来显示正确的东西。实体只是表示，正如我们从 EF 中知道的那样，但是如果将这两者结合起来，模型他的用处在哪里呢？

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

像往常一样感谢并祝周末愉快

Matthias

“模型”一词是有歧义的。他们都是模特。

实体模型

一个与持久性结构非常相似的类。 A成员实体是一种模型，表示数据库中 Members 表中的一个成员行。不严格依赖于数据库，而是某种持久性的实体。通常具有“ID”属性，例如“int MemberID”。

视图模型

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

Notice

...上述两个模型代表应用程序边界上的通信。即接收通信（用户事件和通过协议进行通信）以发起业务规则的前端边界（入口点）；后端边界接受业务规则的命令以与其他系统（例如数据库或其他端点）进行开放通信。

领域模型

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

领域服务

域服务采取实体模型并将它们转化为领域模型所以说服务可以与模型一起工作。如果一个实体从后边界进入并且无法序列化或映射到域模型中，则会出现一个危险信号：数据不好.

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

• 注意：实体符合模型因为坚持是一个细节。域是系统的王，而不是持久性的硬件或表结构。域永远不会错。

前边界采取视图模型并将它们转化为领域模型这样它们就可以传递到域中。如果 ViewModel 无法序列化或映射到域模型，则会出现一个危险信号，表明 view/json/xml 是错误的。

域服务返回领域模型到前边界​​，然后映射到视图模型以便与前方沟通。如果视图/UI 无法接受模型，则需要修复视图。

• 注意：ViewModel 符合 Models因为消费者是一个细节。域是系统的王，而不是使用它们的 UI 或子应用程序。域永远不会错。

ViewModel 永远不知道实体因为 UI/消费者永远不知道持久性的存在。

核心业务逻辑不应该了解视图模型或实体。核心业务逻辑仅适用于领域模型。这就是控制器和它们附近的前端服务存在的原因；映射域模型 ViewModel。这也是 SDK 及其附近的后端服务存在的原因；映射 DomainModels 实体。

当构建系统时，首先构建域和业务逻辑（希望是 TDD）。然后将适配器放置在业务逻辑的前端和后端，确定交付机制（前端）和依赖项（服务/持久性）（后端）。但这些前端和后端可以被剔除，核心业务逻辑仍然存在。

较短版本（TLDR；）：

实体：数据库记录。

领域模型：模型特定的业务逻辑（Google“值对象”），用于表示领域问题中的对象。

ViewModel：视图的页面（或部分）。