【问题标题】:Model classes vs Model in MVCMVC 中的模型类与模型
【发布时间】: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 中的模型类,其中将包含一些字段,如 nameagelocation 等。在hibernate中我会将它声明为一个实体,在数据库中我会为它创建一个表,它会有一个id作为主键。
  • 如果仍然不清楚我将这些实体类引用到什么,我可以提供一个示例作为代码。
  • customer.java 中你的类Customer,如果它只有属性并且是你的底层持久层对象/表的表示,那么它通常被称为数据传输对象(DTO)。模型类包含存储和检索数据的逻辑,并且该数据被塑造/投影为 DTO。这样就不会出现您对两边都有模型的困惑。
  • Spring (ab) 使用著名的模式名称进行营销。这是一种有效的营销策略,但对开发社区造成了极大的伤害,因为它污染了我们的术语。将其与扩展 MVC 并部分重叠的所有不同风格结合起来,您就会发现一堆词只在孤立的上下文中始终如一地使用,但通常在不同的上下文中混为一谈。

标签: spring model-view-controller design-patterns


【解决方案1】:

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

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

  • Data mappers:在实体和选定的持久空间(数据库、会话、可通过 SOAP 访问的远程存储库等)之间传输数据。
  • Repositories:在 entities 和选择的持久空间之间传输数据,虽然通过使用 data mapers 层中的 data mappers。他们在 data mappers 层之外构建了一个层,以便向用户隐藏持久空间的类型。每个 repository 对象都被编码为特定类型的 实体集合,可以以类似集合的方式访问。因此,例如,Book 实体的集合可以命名为 BookCollectionLibraryBooksRepository,并包含用于处理 Book 类型对象集合的方法,例如: “查找/获取/删除/更新/存储/存在/计数/等图书收藏中的图书”
  • 实体域对象:保存特定业务请求的数据和行为。这些组件包含独立于应用程序的业务逻辑。换句话说,它们可以被多个应用程序重复使用。
  • Value objects
  • 服务,作为service layer 的一部分。这些对象也包含业务逻辑,但与实体相比,它们的业务规则依赖于使用它们的应用程序。由于这个事实,是否应该将服务类定义为域模型或交付机制的一部分(参见下面的前两个资源)是有争议的。

因此,在基于 MVC 的应用程序中:

  • 模型不是一个类,而是一层不同职责的对象;
  • 模型包含实体服务中的业务逻辑;
  • 域对象包含数据和行为。

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

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

注意事项:

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

资源:

【讨论】:

  • 谢谢@dakis。但我认为这是一个普遍的答案。我对通常的应用程序中发生的事情很感兴趣,人们把这些事情搞砸了。
  • 不客气,@AlexJ。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-10-26
  • 2014-06-11
  • 2015-03-27
  • 1970-01-01
  • 2011-07-22
  • 2012-11-17
  • 2011-05-02
相关资源
最近更新 更多