MVC 中的模型类与模型

Posted 2023-03-31

【中文标题】MVC 中的模型类与模型

【英文标题】：Model classes vs Model in MVC

【发布时间】：2022-01-05 21:17:23

【问题描述】：

MVC 中的模型是否同时包含业务逻辑（算法和东西）和映射到数据库中实体表的类？那些映射的类也被称为模型，特别是因为它们对一些数据进行建模。我的困惑是：模型是否包含业务逻辑？还是只是实体？事实证明，它包含来自 Mozilla 文档：Model: Manages data and business logic.

我对 Java Spring 项目的结构感到困惑。有控制器、服务（业务逻辑）、存储库（连接到数据库，也称为 DAO）和模型类（控制器接收并通常映射到数据库实体的对象类）。让我们将其映射到 MVC“组件”：

查看 - 不在 spring 应用程序中；

Controller - Rest 控制器（或只是 Controller，取决于您希望如何构建应用程序）；

模型 - 服务、存储库、模型类 (???)。

我很困惑，我们左右两边都有模型。

谢谢。

编辑：添加一个sn-p的代码，以及app的结构。

这是 Spring 应用程序通常的外观。大多数人都在做什么。

.
├── BasicSpringAppApplication.java
├── controller
│   └── CustomerController.java
├── model
│   └── Customer.java
├── repository
│   └── CustomerRepository.java
└── service
    └── CustomerService.java

这是模型/实体在 java 文件中的样子：

package com.example.basicspringapp.model;

public class Customer 
    private String id;
    private String name;
    private String surname;
    private int age;

    //constructors, getters, setters

看看我所说的（以及他们通常所说的）模型，只是一个特定的东西，一个实体。但在 MVC 中，它不仅如此！模型不仅包括实体，还包括服务和存储库，任何不是视图和控制器的东西。

为什么 MVC 模式在通常的 Spring 应用程序中被搞砸了？至少对我来说，这似乎搞砸了。为什么人们不将这些类称为实体或类似的东西？由于模型不止于此，对于 MVC。

【问题讨论】：

嗨。 “映射到数据库中的实体表的类”和“映射到数据库实体的对象的类”是什么意思？更准确地说，您所指的那些“实体表”和“数据库实体”是什么？一些代码也会有所帮助。

@dakis 嘿。你提到的事情是同一个意思。一个例子可以是Customer，作为一个实体。如果您有一个保存客户列表和有关他们的信息的网站，Customer 将是 Java 中的模型类，其中将包含一些字段，如 name、age、location 等。在hibernate中我会将它声明为一个实体，在数据库中我会为它创建一个表，它会有一个id作为主键。

如果仍然不清楚我将这些实体类引用到什么，我可以提供一个示例作为代码。

customer.java 中你的类Customer，如果它只有属性并且是你的底层持久层对象/表的表示，那么它通常被称为数据传输对象（DTO）。模型类包含存储和检索数据的逻辑，并且该数据被塑造/投影为 DTO。这样就不会出现您对两边都有模型的困惑。

Spring (ab) 使用著名的模式名称进行营销。这是一种有效的营销策略，但对开发社区造成了极大的伤害，因为它污染了我们的术语。将其与扩展 MVC 并部分重叠的所有不同风格结合起来，您就会发现一堆词只在孤立的上下文中始终如一地使用，但通常在不同的上下文中混为一谈。

【参考方案1】：

基于 MVC 的应用程序中的模型：

在基于 MVC 的应用程序中，domain model（或简称为 model）反映了某个业务。它被编程为一个层——模型层，或业务层——并且由多个不同类型的对象组成：

Data mappers：在实体和选定的持久空间（数据库、会话、可通过 SOAP 访问的远程存储库等）之间传输数据。 Repositories：在 entities 和选择的持久空间之间传输数据，虽然通过使用 data mapers 层中的 data mappers。他们在 data mappers 层之外构建了一个层，以便向用户隐藏持久空间的类型。每个 repository 对象都被编码为特定类型的 实体集合，可以以类似集合的方式访问。因此，例如，Book 实体的集合可以命名为 BookCollection、Library 或 BooksRepository，并包含用于处理 Book 类型对象集合的方法，例如： “查找/获取/删除/更新/存储/存在/计数/等图书收藏中的图书”。

实体

或

域对象

：保存特定业务请求的

数据和行为

。这些组件包含

独立于应用程序

的业务逻辑。换句话说，它们可以被多个应用程序重复使用。 Value objects。 服务，作为service layer 的一部分。这些对象也包含业务逻辑，但与实体相比，它们的业务规则

依赖于使用它们的应用程序

。由于这个事实，是否应该将服务类定义为域模型或交付机制的一部分（参见下面的前两个资源）是有争议的。

因此，在基于 MVC 的应用程序中：

模型不是一个类，而是一层不同职责的对象； 模型包含

实体和服务中的业务逻辑； 域对象包含

数据和行为。

实体本身不以任何方式映射到任何持久性系统（如数据库）。它们的属性和方法通过使用business-specific vocabulary 反映特定业务，因此完全独立于所选持久性系统的结构。这是数据映射器的责任——而且只有他们的责任！ - 例如，了解和映射域对象的属性和数据库记录的结构。

至少在下面的前两个资源中，您会发现，在基于 MVC 的应用程序中，持久性系统（数据库等）确实不决定了应用程序的结构。 持久性系统“只是一个细节”。

注意事项：

将 services 旁边的 model 层 的其他组件注入控制器会导致其中错误地包含业务逻辑。控制器的唯一目的应该是将用户请求的处理委托给服务层。 object-relational mapping 系统 (ORM) 的优缺点值得商榷。

资源：

Keynote: Architecture the Lost Years Robert C. Martin Sandro Mancuso : Crafted Design How should a model be structured in MVC? Unbreakable Domain Models 和 slides DDD Building Blocks: Value Object Validating Value Objects A definition of the Ubiquitous Language Alejandro Gervasio的教程，php代码：Building a Domain Model – An Introduction to Persistence Agnosticism,Building a Domain Model – Integrating Data Mappers,Handling Collections of Aggregate Roots – the Repository Pattern,An Introduction to Services Challenges of object–relational mapping, Object–relational impedance mismatch

【讨论】：

谢谢@dakis。但我认为这是一个普遍的答案。我对通常的应用程序中发生的事情很感兴趣，人们把这些事情搞砸了。

不客气，@AlexJ。