MVC设计思想

MVC

MVC = Model + View + Controller

---

---

前言

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、关于MVC

MVC为设计软件提供了基本的思想，它认为每个软件都应该至少包含这3大部分，且各部分分工明确，只负责整个数据处理流程中的一部分功能。

例如V通常表现为“软件的界面”，用于呈现数据、提供用户操作的控件。

而C表示控制器，用于接收请求、响应结果，并不会处理实质业务。

而M表示数据模型，通常由业务逻辑和数据访问这2部分组成，在开发实践中，数据访问通常指的就是数据库编程，而业务逻辑是由专门的类来实现的，这样的类通常使用Service作为类名的关键字。

在整个数据处理过程中，将会是：Controller调用Service，而Service调用Mapper。

业务逻辑的主要职责是：设计业务流程，处理业务逻辑，以保证数据的完整性和安全性。

# 关于接收请求

需要自定义类，在类上添加@Controller / @RestController注解，则此类就是控制器类。

通常，建议在类上也添加@RequestMapping配置请求路径中的前缀部分。

在类中自定义处理请求的方法：

• 注解：添加@RequestMapping系列注解来配置请求路径和某些参数
• 访问权限：应该使用public
• 返回值类型：在前后端分离的开发模式下，应该使用自定义的数据类型，例如JsonResult
• 方法名称：自定义
• 参数列表：当请求参数数量只有1个时，或少量参数且没有相关性，直接写，当请求参数数量超过1个且具有相关性时，应该封装为自定义的数据类型（开发中常定义为DTO，数据传输对象），并使用自定义的数据类型作为参数

#关于接收的请求参数

如果要求客户端提交的请求参数是JSON格式的，则处理请求的方法的参数列表中，封装的数据类型必须添加@RequestBody注解，如果要求提交的请求参数是FormData格式的，则不可以添加@RequestBody注解。

如果某个请求参数是URL的一部分，在使用@RequestMapping系列注解配置请求路径时，需要使用{}格式的占位符，例如/albums/{id}/delete，并且，在处理请求的方法的相关参数上，添加@PathVariable注解。

另外，还可以在请求参数上添加@RequestParam，此注解可以指定请求参数名称、限制必须提交、配置默认值，但此注解并不是必须的。

# 开发Service

Service的开发规范是先写接口，再写实现类。

通常，会在项目的根包下创建service子包，Service接口将存放在这个包中，并且，还会在service包下创建impl子包，Service实现类都将放在这个包中，实现类都会使用ServiceImpl作为类名的后缀。

例如：在项目的根包下创建service.IAlbumService接口，然后，再创建service.impl.AlbumServiceImpl类，且此类将实现IAlbumService接口。

为了保证项目启动时可以正确的创建此实现类，需要类上添加@Service注解。

假设需要实现：添加相册。

则在接口中添加抽象方法，关于抽象方法的设计：

• 返回值类型：当客户端提交了相应的请求到服务器端，业务逻辑层正确的处理了数据后，是否需要返回某个数据（设计返回值类型时，不需要考虑失败的情况，因为将通过抛出异常来表示失败）
• 方法名称：自定义
• 参数列表：所有应该由客户端提交的数据属性

void addNew(AlbumAddNewDTO albumAddNewDTO);

然后，在实现类中：

@Override
public void addNew(AlbumAddNewDTO albumAddNewDTO) {
   
    log.debug("开始处理【添加相册】的业务，参数：{}", albumAddNewDTO)